1.0  B“  U4 


«  Li  12.0 


i  18 

iflBI 


1.25 


Lit 


U|s£ 

IUe 


MICROCOPY  RESOLUTION  TEST  CHART 
NATIONAL  BUREAU  OF  STANDARDS- 1963 -A 


MICROCOPY  RESOLUTION  TEST  CHART 
NATIONAL  BUREAU  OF  STANDARDS-  1963-A 


1.0  S 


Li  i2jj  1 2.5 


1m  12,2 

gf  |L  “ 

S  148  110 


L25  MU  11.6 


MICROCOPY  RESOLUTION  TEST  CHART 
^  NATIONAL  BUREAU  OF  STANDARDS- 1963-A  f 


1.0  S 


Li  1*8  |2_5 

m  . 

£  1^  1 2.2 

II  Wbbb 

“  L8  |Z0 


Im  iLi  Li 

iihiks  wit^M  mm 


1.0  S“  IN 

BB  £  “  Li 

■  I  I.1"  Li 

1*1  btok 


suit 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BU'iCAU  Of  STANDARDS- 1 963-A 


I 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANOARDC-19W-A 


one  FILE  COPY 


R  ADC-TR-82- 175 
Final  Technical  Report 
June  1982 


JOVIAL  (J73)  TO  ADA  TRAMSUm 


Proprietary  Software  Systems,  Inc. 


Mark  Nelman 


Qocri9,a*$B 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTE  URLIMITED 


ROME  AIR  DEVELOPMENT  CENTER 
Air  Force  Systems  Command 
Griff iss  Air  Force  Base,  NY  13441 


82  i  o 


■  V 


,y '  .•;>:  ? 


<  *  Vi  Vu  X  V  ^  ;;  A;  '  5^ 

V  ^  y  *  **  •  *  •  r’  it  *i*\ 

-.  .  ...  -  •  ’A'  •  .  •  /  :  :  r,  ..'■*•>•  ■  ~.-i 

,  ,  '  '-  >4^'  •'  <-  ■*■,.<•  .  *■*'  ;  «■$  '  .Ji 


iSp|  W. 

v  ‘ 


v.-£ 


t  '*  ‘f'Li, 


I- v¥^$0&‘-  1 


,*i^ 


:■  -V. 


t 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  Face  (Wlton  Om/nnnO 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER  2.  GOVT  ACCESSION  NO. 

RADC-TR-82-175  </7l 

).  recipient's  catalog  numecr 

a" 

4.  TITLE  (out  Submit) 

JOVIAL  (J73)  TO  ADA  TRANSLATOR 

S.  TYPE  OF  REPORT  4  PERIOD  COVERED 

Final  Technical  Report 

Jun  1981  -  March  1982 

4.  performing  org.  refort  number 

N/A 

7t  AUTwONfA) 

Mark  Neiman 

S.  CONTRACT  OR  GRANT  NUMBERT*; 

F30602-81-C-0217 

».  PERFORMING  ORGANIZATION  NAME  ANO  AOORESS 

Proprietary  Software  Systems,  Inc. 

9911  West  Pico  Blvd,  Penthouse  K 

Los  Angeles  CA  90035 

10.  FROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  4  WORK  UNIT  NUMBERS 

627 02F 

55811917 

It.  CONTROLLING  OFFICE  NAME  ANO  AOORESS 

Rome  Air  Development  Center  (COES) 

Griffiss  AFB  NY  13441 

12.  RSRORT  OATS 

June  1982 

IS.  NUMBER  OF  PAGES 

122 

14.  MONITORING  AGENCY  NAME  •  AOORESSflf  dlllorunl  hum  Controlling  Olllcm) 

Same 

IS.  SECURITY  CLASS,  (ol  Olio  ropolt) 

UNCLASSIFIED 

tla.  OCCLASSIFICATION/OOWNGRAOING 

t«.  OISTKISUTION  STATEMENT  (ot  thi*  Ropoet) 

Approved  for  public  release;  distribution  unlimited 

17.  DISTRIBUTION  STATEMENT  (ot  Him  obolrott  onlond  In  Bio o*  it.  It  dllloronl  hum  Ruuutt) 

Same 

IS.  SUFFL EMENT ANY  NOTES 


RADC  Project  Engineer:  Elizabeth  S.  Kean  (COES) 


IS.  KEY  WORDS  (Comlnuo  on  nnm  1W1  II  aMnwr  UN  Idonlllr  Ir  MM*  MhfJ 

JOVIAL 

Ada 

Translator 

Compiler 

-frgnt-snd _ _ - 

JO.  ABSTRACT  fCoiiWM  an  nmn  ME*  II  nouooomf  M  MnM*  *F  Mm*  ihmMtJ 

This  document  contains  the  functional  description  and  system/ subsystem 
specifications  for  a  JOVIAL  J73/Ada  translator,  and  guidelines  for  J73 
programmers  who  anticipate  their  programs  will  be  converted  to  Ada  at  a 
later  date.  The  functional  description  specifies  the  maximum  JOVIAL  J73 
subset  that  can  be  converted  to  Ada.  Techniques  for  the  optimum  automatic 
translation  of  the  source  code  are  specified.  The  J73  constructs  that 
cannot  be  automatically  translated  are  identified.  The  system/ subsystem 

00  ,  1473  COITION  OF  I  NOV  *»  I*  OOSOLETt  UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  FACE  fRBan  Oat*  Z5 tarM) 


UNCLASSIFIED 


mcBimngggffl  u.u  ■fis.TTwi  ^ 


specification  provides  a  more  detailed  breakdown  of  the  proposed 
translator.  ^ — 


Accession  Far 

NTIS  GRAAI 
OTIC  TAB 

Unannounced 

Jjstiflcatlor 


Distribution/ _ 

~Ava liability  Codes 
'Avail  and/or 
Dlyt  Special 

l  i 


ucuntTv  cu*(fi'ieArioa  o*  T“,e  *ao«(v*i«i  o 


FUNCTIONAL  DESCRIPTION 


for  tho 

JOVIAL  (J73)  TO  ADA  TRANSLATOR 


Pro*»r#d  bvi 
Mark  J.  Noimtn 


TABLE  OF  CONTENTS 


Paragraph 


SECTION  1 

1.1 

1.2 

1.3 


GENERAL 

Purpose  of  the  Functional  Description 

Project  References........ . . 

Terms  and  Abbreviations . 


SECTION  2 

2.  1 
2.2 

2.3 

2.4 

2.4.1 

2.4.2 

2.5 


SYSTEM  SUMMARY 

Background . . . . . 

Objectives. .................... 

Existing  Methods  and  Procedures 
Proposed  Methods  and  Procedures 
Summary  of  Improvements........ 

Summary  of  Impacts . . 

Assumptions  and  Constraints.... 


SECTION  3 

3. 1 

3.1.1 

3.1.2 

3.2 

3.2.1 

3.2. 1.1 

3.2. 1.2 

3.2.1. 2.1 

3.2. 1.2.2 
3.2. 1.3 

3.2.2 

3.2.2. 1 

3.2. 2.2 

3.2.2.2.1 

3. 2. 2. 2. 2 

3. 2. 2. 2. 3 

3.2. 2.2.4 
3.2.3 

3.2.3. 1 

3. 2.3.2 

3. 2.3.3 

3.2.4 

3.2.5 


DETAILED  CHARACTERISTICS 

Specific  Performance  Requirements. ... , 

Accuracy  and  Validity... . . 

Timine  and  Capacity . 

System  Functions . 

Proeram  Structure . . . 

Modularity*  Compools  and  Packages. . . . 

Context-Dependent  Declarations . 

Procedure  Specification . 

Externals. . . . . . 

Summary . . . . . 

Types  and  Declarations . 

Predefined  Types. . 

Type  and  Object  Declarations......... 

Scalar  Types. . . 

Tables . . . . . 

Pointers. . . . . . 

Other  Declarations . . 

Executable  Constructs. ............... 

Expressions  and  Assivnments . 

Local  Control  Statements..... . . 

Call  and  Return  Constructs.. . . 

Directives. . . 

Intrinsic  Functions . 


P-iii 


fob 1 o  of  Contents  -  Continued 


3.2.6  Miscel loneous  Functions .  F-47 

3.2.6.  i  Ntntf..... . F-47 

3. 2. 6.2  Common ts. . . . F-49 

3. 2. 6. 3  Prettyprintino. . F-50 

3.3  Inputs-Outputs. . . .  F-S2 

3.3.1  Input  Do  to..... . F-S2 

3.3. 1.1  Usor  Commond  Input . . . F-52 

3.3. 1.2  J73  Sourco  Input.. . . . F-52 

3.3. 1.3  Tronslotion  Poromotor  Input .  F-52 

3.3.2  Output  Producod.  .  .  . . .  F-53 

3.3.2. 1  Tronslotod  Ado  Modulo  Output .  F-53 

3. 3. 2. 2  Gonorotod  Ado  Modulo  Output .  F-53 

3. 3. 2. 3  Proorom  Dictionory  Output .  F-53 

3.4  Doto  Choroctor istics . F-54 

3.5  Foiluro  Continooncios. . .  F-54 

APPENDIX  1<  Summory  of  Problomoticol  Constructs .  F-Al 

APPENDIX  21  MIL-STD-1589B  Cross  Roforonco .  F-A2 


JOVIAL  TO  ADA  TRANSLATOR  INVESTIGATION 
FUNCTIONAL  DESCRIPTION 


SECTION  1 .  GENERAL 

1.1  PURPOSE  OF  FUNCTIONAL  DESCRIPTION 

This  Functional  Description  for  tho  JOVIAL  (J73)  to  Ada  Translator 

Investigation  ( F30602-8 1 -C-02 1 7 )  is  written  to  provide* 

a.  The  system  requirements  to  be  satisfied  which  will  serve 
as  a  basis  for  mutual  understandins  between  potential 
users  and  developers  of  a  J73  to  Ada  Translator. 

b.  Information  on  performance  requirements,  preliminary 
desien.  user  impacts,  and  costs. 

c.  A  basis  for  the  development  of  system  tests. 
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1.2  Project  Reference* 

«.  Statement  of  Work,  contract  F30602-81-C-0127,  RADC/PSS. 
June  1981. 

b.  Technical  Proposal  in  response  to  RFP  F 30602-8 1 -R-0058 » 
RADC/PSS.  January  1981. 

c.  "Translation  of  CMS-2  Proerams  to  Ada."  bv  Oilman. 
Crocker.  Taylor.  USC  Information  Sciences  Inst.. 
February  1980. 

d.  "Source-to-Sourc*  Translation!  Ada  to  Pascal  and  Pascal 
to  Ada."  ACM  SIGPLAN  Symposium  Proceedines.  1980, 

e.  MIL-STD-1813  -  Reference  Manual  for  the  Ada  Proerammine 
Laneuaee.  December  1980. 

f.  Bcoacaam±na-±n_Ada .  by  J.  G.  P.  Barnes.  1981. 

* .  Bcoecamaioa — with — AdaX — An ln±coducXi.oo bx Means of 

Gcaduatad-Examele*.  by  P.  We near.  1962. 

h.  "Self-Assessment  Procedure  VIII."  ACM  Comm.  Vol.  24.  no. 
10.  by  P.  Weneer. 

I.  Comeutec.  June.  1981. 

J.  "Proerammine  Manual  for  JOVIAL  <J73>".  Softech. 

k.  "Software  Eneineerine  Exchanee.”  IBM  FSD.  October  1980. 
Vol.  3.  no.  1. 

l.  "Rationale  for  Desien  of  the  Ada  Laneuaee."  ACM  SIGPLAN 
Notices.  Vol.  14.  no.  6.  Part  B. 

m.  DIANA-Befeceoce-Maoual.  by  Goos  fc  Wulf.  March  1981. 

n.  Computer  Proeram  Development  Specifications,  by  T.I.  and 
Intermetrics  (Compiler/Environment).  March  1981  Drafts. 

o.  M I L-STD- 1 589B  -  JOVIAL  <J73>. 

p.  F.C.S.C.  Conversion  Products/Aids  Survey.  Report 
GSA/FCSC-8 1/004. 


e.  J0U1AI — __iJZ31 — ta — Ada Icanslatoc—Sxaiem.  by  R.  L. 

Brozovic.  Master's  Thesis  < AFIT) .  December  1980. 
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1.3  Terms  and  Abbreviation* 

The  followine  term*  end  ebbrevietions  will  be  used  throughout  this 

Functional  Description* 

Erroneous  A  ..  hi*h  order  laneuaee  proeram  which  contains 
one  or  more  violations  of  laneuaee  semantics 
which  are  not  detected  bv  a  compiler. 

Erroneous  prosrems  have  unpredictable  run-time 
results. 

External  A  proeram  element  that  is  referenced  by 

modules  which  are  compiled  separately  from  the 
module  in  which  the  element  is  declared. 

J73  The  proerammine  laneuaee  JOVIAL  (J73)  as 

specified  by  MXL-STD-1589B. 

Module  A  portion  of  a  J73  or  Ada  Proeram  which  is 

loeically  distinct  from  the  rest  of  its 
proeram  and  which  may  be  compiled  or 
translated  separately. 

Proeram  All  of  the  modules  of  a  J73  or  Ada  proeram.  as 

opposed  to  an  individual  compilation  unit. 

TPF  Translation  Parameter  File  -  a  user  accessible 

file  which  specifies  which  translation  options 
will  be  used  for  a  run  of  the  Translator. 

Translator  The  proposed  JOVIAL  (J73)  to  Ada  translator. 
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SECTION  2.  SYSTEM  SUMMARY 
2. 1  Background 

The  Department  of  Defense  is  currently  ensased  in  a  Ions  term  effort 
to  define  and  develop  a  new  hieh  order  programming  lansuase*  Ada.  Ada 
is  to  be  used  as  the  standard  implementation  tool  for  embedded 
computer  systems.  Standardized  and  validated  Ada  compilers  and 
environments  will  not  be  available  for  another  year  or  two!  moreover, 
many  new  and  onsoin9  Air  Force  projects  are  usins  the  present  standard 
lansuase*  JOVIAL  (J73>*  for  implementation  of  real-time  software 
systems.  The  need  for  a  JOVIAL  <J73)  to  Ada  Translator  is  driven  by 
two  major  problems: 

a.  Existins  software  written  in  J73  will 
eventually  be  used  in  Ada-based  systems. 

b.  Software  developed  durins  the  Ada  development 
period  (1980-1984)  cannot  use  Ada  exclusively 
and  therefore  must  be  written  in  J73. 

A  Translator  would  enable  J73  programs  to  be  converted  to  the  new 
standard  lansuase  so  that  the  advantases  of  maintainability  and 
universality  of  Ada  may  be  exploited.  The  translator  will  be  needed 
not  only  durins  the  Ada  development  period*  but  also  afterwardl  future 
maintainers  of  embedded  systems  will  be  experts  in  the  use  of  Ada  and 
the  Ada  Prosrammins  Support  Environment  (APSE)  rather  than  JOVIAL. 
These  maintainers  will  benefit  sreatly  from  havins  a  J73  to  Ada 
Translator  as  *  part  of  the  APSE. 


2.2  Objectives 

The  objective  of  the  proposed  JOVIAL  (J73)  to  Ada  Translator  is  the 
automatic  translation  of  J73  source  prosrams  to  equivalent  Ada  source 
prosrams.  Because  some  J73  constructs  cannot  be  automatically 
translated  to  Ada*  the  Translator  must  detect  and  flas  any  constructs 
which  it  does  not  translate. 

Another  soal  of  the  Translator  is  flexibility.  A  number  of  J73 
constructs  have  two  (or  many)  possible  Ada  translations.  The  user  may 
wish  to  control  some  or  all  of  the  choices  made  by  the  Translator. 
This  will  require  parameterization  of  the  translation  options*  with  a 
user-accessible  file  for  the  parameter  values. 
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*ical  J73  program  consists  of  many  separately 
share  data  specifications  using  the  DEF, 
'gets.  Translation  of  individual  J73  modules 
preserve  the  semantics  of  J73  compools  and 
ting  in  well  structured  Ada  programs*  is 
tive. 


compiled  modules 
REF,  and  COMPOOL 
into  Ada  modules 
externals,  while 
a  major  design 


jgh  the  Translator  is  designed  as  a  stand-alone  product,  it  is 
Loned  as  a  part  of  the  Ada  Programming  Support  Environment.  With 
i«1p  of  compilers,  text  editors,  file  managers,  and  other  APSE 
>  the  Translator  will  provide  significant  (though  not  total) 
ition  of  the  conversion  of  J73  programs  for  use  in  the  Ada 
Dnment. 

Existing  Methods  and  Procedures 


are  no  existing  implementations  of  a  Translator  which  satisfy 
objectives  described  in  the  preceeding  paragraph.  Many  automatic 
lators  exist  for  simpler  languages  such  as  COBOL,  FORTRAN,  RPG, 
numerous  assembly  languages,  but  at  present,  the  only  method  of 
/ina  production  quality  translation  of  J73  to  Ada  is  manual 
lation. 

»e  Ada  compilers  and  environments  do  not  yet  exist  in  complete, 
ited  implementations,  one  may  assume  that  very  little  manual 
lation  of  J73  to  Ada  has  been  performed.  However,  if  manual 
istion  is  to  be  performed,  two  major  ingredients  are  required. 
First  is  a  set  of  rules,  which  may  be  as  formal  as  a  language 
<  specification  or  as  informal  as  a  set  of  rules  and  procedures, 
specify  the  mapping  of  J73  onto  Ada.  The  second  is  a  programmer 
'oup  of  programmers  who  are  experts  in  both  languages.  While  the 
I  ingredient  is  somewhat  rare,  the  first  is  probably  nonexistent, 
ation  of  large  programs  (i.e.,  several  hundred  modules)  would  be 
►  itively  expensive,  even  if  both  ingredients  were  acquired, 
'er,  a  manual  translation  of  a  large  realtime  system  would  be 
:t  to  much  human  error  and  inconsistency!  the  final  product  would 
>e  "flyable"  without  very  extensive  redesign  to  remove  :he 
rable  translation  errors. 

’roposed  Methods  and  Procedures 

"ranslator  proposed  in  this  document  is  intended  to  automate  the 
ation  of  J73  to  Ada  to  the  largest  extent  practical.  Although 
automation  may  be  impossible,  it  is  anticipated  that  80-95X  of 
fort  involved  in  manual  translation  will  be  removed.  In  addition 
anslating  nearly  all  of  a  J73  program  to  equivalent  Ada,  the 
ator  will  detect  untranslatable  code  and  will  generate  stub 
s  for  additional  Ada  code  required  bv  the  translated  program. 
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2.4.1  Summary  of  Improvements 

The  improvements  of  automatic  translation  over  manual  translation  are 
summarized  belowt 

a.  Vastly  increased  throughput. 

b.  Greater  consistency. 

c.  The  Translator  mill  be  nuite  thorough,  either 

translatin*  or  fla**in*  everythin*  in  the  J73  prosram.  A 
human  translator  mi*ht  inadvertantly  omit  a  part  of  the 
program. 

d.  Greater  flexibility.  If  a  certain  aspect  of  the 

translation  appears  unacceptable.  a  different 

translation  could  be  obtained  by  chansin*  parameters  and 
re-runnin*  the  Translator.  This  would  be  unfeasable  for 
manual  translation. 

e.  Reduced  cost.  The  cost  of  automatic  translation  of  J73 
modules  would  approximately  enual  the  cost  of  compilin* 
the  modules.  The  additional  costs  involved  in  completin* 
the  translation  of  a  prosram  (manually  translatin*  or 
reprosrammins  the  untranslatable  portions)  would  be  much 
less  than  the  time  and  money  saved  by  automatin*  the 
bulk  of  the  translation  process. 


2.4.2  Summary  of  Impacts 

Since  there  are  no  onsoin*  J73  to  Ada  translation  projects,  there  are 
assumed  to  be  no  impacts  on  equipment,  software,  orsanizations.  or 
operations.  The  Translator  would  be  developed  on  an  existin* 
medium-to-1 ar*e  scale  computer  system,  and  its  installation  would  be 
similar  to  that  of  any  other  stand-alone  software  system. 


2.5  Assumptions  and  Constraints 

The  Translator  described  in  this  document  is  assumed  to  process 
correct  J73  programs  and  to  output  correct  Ada  programs.  The  sense  in 
which  the  input  and  output  are  considered  to  be  "correct"  is  discussed 
in  paravraphs  3.1.1  and  3.3. 1.2. 
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SECTION  3.  DETAILED  CHARACTERISTICS 

3.1  Specific  Performance  Requirements 

This  paragraph  describes  the  performance  requirements  to  be  satisfied 
bv  the  Translator  with  reeard  to  accuracy*  validity*  timine  and 
capacity. 

3.1.1  Accuracy  and  Validity 

The  translations  performed  by  the  Translator  will  be  accurate  in  the 
sense  that  the  resulting  Ada  programs  will  be  semantically  equivalent 
to  the  J73  programs  from  which  they  were  derived  to  the  lareest  extent 
possible.  Except  for  certain  untranslated  constructs*  which  will  be 
clearly  flaeeed  in  the  output*  the  Ada  produced  by  the  Translator  will 
be  a  valid  Ada  proeram  in  that 

a.  It  will  contain  no  syntax  errorsi 

b.  Any  missine  code  that  is  required  for  execution  of  the 
proeram  will  be  clearly  identified! 

c.  It  will  be  compilable  in  a  standard  Ada  environment 
without  modifications  (such  as  reoreanizine  statements 
and  declarations  or  renamine  modules  or  variables)! 

d.  It  will  conform  to  eeneral  standards  for  readable*  well 
structured  proerammine. 

In  eeneral*  two  versions  of  a  proeram  cannot  be  euaranteed  to  have 
absolutely  identical  run-time  behavior  in  two  different  environments* 
even  if  the  versions  were  eenerated  from  the  same  source  code  (e.e.«  a 
J73  proeram  compiled  for  two  different  tareets).  Therefore*  the 
Translator  cannot  be  required  to  produce  a  "perfect"  translation  of  a 
non-trivial  proeram.  However*  it  will  be  required  to  preserve  the 
orieinal  proeram  semantics  wherever  possible*  at  the  expense  of  some 
run-time  efficiency  if  necessary*  and  to  inform  the  user  of  any 
possible  deviations  from  J73  semantics  that  are  introduced  by  the 
translation. 


3.1.2  Timine  and  Capacity 

Althoueh  portions  of  a  proeram  stay  require  repeated  translation  to 
resolve  various  translation  problems*  the  overall  translation  process 
will  be  a  one-time  task.  Hieh  performance  with  respect  to  throuehput 
is*  therefore*  not  eiven  a  hieh  priority.  The  Translator  should 
process  J73  source  code  at  about  the  same  speed  as  a  compiler*  rouehly 
100-1000  source  lines  per  CPU  second  on  a  typical  mainframe  host 
system. 
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The  Translator  and  its  host  environment  must  hava  tha  capacity  to 
stora  and  process  an  antira  J73  proaram  at  ona  tima.  This  typically 
maans  a  capacity  on  tha  ordar  of  1000  modulas  of  90-200  sourca  linas 
aach  for  a  laraa  fliaht  software  system. 


3.2  System  Functions 

This  paragraph  describes  tha  specific  functions  to  be  performed  by  tha 
Translator.  These  functions  can  be  considered  to  comprise  an  informal 
specification  of  a  mappine  of  tha  J73  lanauaae  onto  tha  Ada  lanauaae. 
The  mappina  is  described  in  six  parts* 

a.  Proaram  Structure 

b.  Types  and  Object  Declarations 

c.  Executable  Constructs 

d.  Directives 

e.  Intrinsic  Functions 

f.  Miscellaneous  Issues 

The  followina  subparaaraphs  describe  each  of  these  functions  by 
providina  a  rationale  for  the  particular  mappines  selected. 


3.2.1  Proaram  Structure 

This  subparaaraph  describes  translation  functions  which  are  related  to 
proaram  structure.  includina  modules,  externals,  and  procedure 
specifications. 


3.2. 1.1  Modularity*  Compools  and  Packaees 

J73  proarams  are  written  as  separately  compiled  modules.  Typically,  an 
individual  module  will  consist  of  either  a  compool  or  a  small 
procedure,  either  of  which  may  include  external  compool  references. 
The  Translator  must  be  compatible  with  this  kind  of  proaram  structure, 
permittins  both  alobal  compool  references  and  efficient  translation  of 
small  modules.  These  aoals  are  not  obviously  in  aareementi  alobal  data 
referencina  implies  knowledae  of  many  modules  durina  a  sinale  module's 
compilation.  The  JOVIAL  environment  satisfies  these  aoals  by  creatina 
compool  output  files  when  compilins  compools.  Small  modules  which 
reference  compools  are  compiled  separately  and  efficiently  by  readina 
the  (previously  created)  compool  output  files.  Unfortunately,  there  is 
no  "standard  compool  output  file"  format  —  each  compiler  has  its  own 
private  format.  Satisfyina  the  aoals  mentioned  above,  therefore, 
presents  a  major  problem  for  the  Translator. 
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Individual  J73  compool  modules  will  be  translated  to  Ada  packaee 
specifications.  This  will  permit  other  modules  to  use  the  resources  of 
separately  compiled  (and  separately  translated)  compool  modules  usine 
a  WITH  clause.  For  example,  a  compool  module 

START 

COMPOOL  alobal variables; 

BEGIN 

"sequence  of  declarations*' 

END 

TERM 

will  be  translated  to 

PACKAGE  *1 obal variables  IS 

—  sequence  of  declarations 
END  el obal variables! 

A  compool  directive 

! COMPOOL  el obal variables; 

will  become 

WITH  el obal variables; 

makine  the  sequence  of  declarations  in  "el obal variables"  available  to 
the  module  containine  the  WITH  clause.  This  translation  precisely 
reflects  the  J73  semantics  of  compool  usaee.  includine  the  order  of 
compilation!  the  compool /packaee  must  be  compiled  before  it  may  be 
referenced,  and  the  content  of  the  compool /packaee  must  be  part  of  the 
compilation/translation  environment.  If  these  conditions  are  met.  then 
the  Translator  will  satisfy  the  eoal  of  preservine  a  J73  program's 
modular  structure  while  translating  it  to  Ada. 

A  more  detailed  example  will  illustrate  how  this  translation  process 
handles  multiple  and  partial  compool  use.  Two  compool s 

START 

COMPOOL  comp 11 
BEGIN 

"declarations  of  variables  AA.  BB" 

END 

TERM 

START 

COMPOOL  come2! 

BEGIN 

"declarations  of  variables  CC.DD" 

END 

TERM 
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will  become  th*  packawes 
PACKAGE  compl  IS 

—  declarations  of  variables  AA.BB 
END  compl I 

PACKAGE  comp2  IS 

—  declaration*  of  variables  CC.DD 
END  comp2; 

Another  compilation  unit  which  use*  compl  and  part  of  comp2 

! COMPOOL  compl I 
! COMPOOL  comp2  CCl 


"references  to  AA.BB* CC" 

will  be  translated  to 

WITH  compl »  comp2t 
USE  compl*  comp2! 

—  references  to  AA*BB*CC 


The  USE  clause  makes  the  variables  declared  in  compl  and  comp2 
directly  visible  in  the  Ada  module.  If  the  USE  clause  were  omitted* 
those  variables  would  need  to  be  qualified  with  their  correspondin* 

packaee  names* 

WITH  compl*  comp2 


—  references  to  comPl.AA*  compl. BB*  comp2.CC 

The  dotted  notation  will  be  used  for  names  which  are  imported  by  a 
partial  compool  directive.  This  will  avoid  ambiwuitv  in  case  the  same 
name  was  declared  (but  not  imported  from)  another  compool.  For  names 
imported  by  a  complete  compool  directive*  there  will  be  no  ambieuitv 
in  rewards  to  which  packawe  a  variable  belonws*  and  the  dotted 
notation  may  be  avoided  by  includinw  a  USE  clause  in  the  packawe  or 
procedure  specification. 
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A  J73  prosram  which  contains  declarations  of  the  same  name  in  more 
than  on*  compool  is  *rron«ou>.  Th*  J73  compiler  will  not  necessarily 
detect  this  error  (but  the  linker  would).  It  is  interesting  to  note 
that  such  a  prosram.  after  beinw  translated  to  Ada  in  the  manner 
described  above,  would  always  be  diasnosed  air  compile  time.  This  is 
true  because  Ada  requires  disambiguation  of  all  references  durin* 
compilation,  while  J73  does  not. 

Another  interestin#  aspect  of  this  translation  technique  is  that  the 
distinction  between  a  complete  compool  directive  and  a  partial  compool 
directive  is  removed.  Partial  compool s  are  specified  in  J73  as  an  aid 
to  efficient  compilation!  the  compiler  knows  that  it  need  not  bother 
reading  all  of  the  compool  file  into  its  symbol  table,  and  may  read 
only  what  is  needed.  A  module  will  have  the  same  meanine  as  if  it  had 
requested  the  entire  compool.  but  will  compile  faster  and  in  less 
space.  The  Translator  will  ienore  this  distinction  for  two  reasons* 

(1)  There  is  no  straiehtf orward  Ada  version  of  a  partial 
compool  directive  -  packages  are  used  only  in  entirety. 

(2)  The  Translator  will  model  the  Ada  environment  in  the 
sense  that  it  will  have  elobal  knowledge  of  slobal  and 
external  objects  durin*  translation,  and  will  not  need 
to  input  compool  data  on  a  module-by-module  basis.  This 
is  discussed  further  in  paragraph  3.2. 1.3. 

3.2. 1.2  Context-Dependent  Declarations 

J73  permits  the  programmer  to  make  objects  either  static  or  externally 
visible  on  an  explicit,  declaration-by-declaration  basis.  Examples* 

ITEM  eternal  STATIC  S! 

DEF  ITEM  external  Si 

These  items  are  either  statically  allocated  or  external Iy' visible 
resardless  of  the  context  in  which  the  declarations  appear.  This 
concept  does  not  exist  in  Ada.  Objects  are  "allocated"  or 
"externalized"  in  Ada  according  to  context.  A  variable*  for  example* 
will  be  static  only  if  it  is  declared  outside  of  any  kind  of  local 
structure*  such  as  a  procedure  or  function!  it  will  be  externally 
visible  only  if  it  is  declared  in  a  package  specification  or  procedure 
specification.  Translation  of  procedures  containing  explicit  STATIC 
and  DEF  declarations*  therefore*  is  really  a  prosram  structure  issue* 
and  is  discussed  in  the  next  two  parasraphs. 
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3.2. 1.2. 1  Procedure  Specification 

In  their  simplest  forme*  J73  procedures  end  functions  mev  be 
trensleted  directly  to  Ade  procedures  end  functions.  For  exemple*  the 
J73  procedure 

START 

•COMPOOL  comp I I 
DEF  PROC  prod! 

BEGIN 

"locel  decleretions  end  executeble  stetements" 

END 

TERM 

becomes  the  very  similer  Ade  procedure 

WITH  complf 
PROCEDURE  prod  IS 
BEGIN 

—  locel  decleretions  end  executeble  stetements 
END  prod! 

This  streiehtf orwerd  trensletion  is  correct  only  if  the  "locel 
decleretions"  included  no  instences  of  the  J73  "DEF"  or  "STATIC" 
constructs.  For  exemple*  if 

START 

DEF  PROC  Proc2l 
BEGIN 

ITEM  xx  STATIC  Si 

"...the  rest  of  the  procedure" 

END 

TERM 

were  trensleted  es  in  the  preceedine  exemple*  the  verieble  xx  could 
not  be  mede  stetic.  Ade  hes  no  explicit  construct  for  declerin*  locel 
stetic  detef  enythin*  declered  inside  e  procedure  body  is  implicitly 
eutometic*  existing  only  when  the  procedure  is  invoked.  Whet  is  needed 
is  en  Ade  structure  which  provides  locel itv  (hidine  the  decleretion 
from  other  procedures)  while  el  so  providing  permenent  existence  for 
the  dete  be in*  declered.  This  is  eccomplished  by  the  Ade  peckese* 
declerin*  the  verieble  inside  e  peckese  body  but  outside  the  procedure 
body  will  meke  the  verieble  stetic  end  locel.  The  only  complicetion  is 
the  neme  of  the  peckese.  The  procedure  "proc2"  mey  be  trensleted  to 
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PACKAGE  proc2_pack  IS 

PROCEDURE  proc2l  —  specification  of  proc2 

END  proc2_packf  —  end  of  packaoo  specif ication 

PACKAGE  BODY  eroc2_pack  IS 

xxt INTEGER!  —  inside  packaoo  body  but  outside  proc  body 

PROCEDURE  proc2  IS  —  body  of  eroc2 

BEGIN 

—  the  root  of  tho  procoduro 
END  proc2l 

END  proc2_packi  —  end  of  packaoo  body 

In  this  translation*  xx  is  local  to  tho  packaoo  proc2_pack*  but  sine# 
proc2_pack  contains  nothinp  but  tho  procoduro  proc2*  xx  is  offoctivoW 
local  to  proc2.  However*  tho  doclaration  of  xx  outsido  of  tho 
procoduro  body  onsuros  that  storaoo  Mill  bo  allocated  for  tho  life  of 
tho  packaoo*  rather  than  Merely  for  tho  life  of  an  invocation  of 
proc2.  Since  packaees  are  inherently  static*  xx  Mill  bo  static.  (Notei 
an  Ada  construct  that  is  inherently  dynaaic  rather  than  static  is  tho 
task.  This  construct  does  not  appear  to  bo  necessary  for 
representation  of  J73  pros rams. )  The  packaee  makes  the  name' “rroc2" 
visible  to  other  compilation  units  by  includine  a  specification  of 
proc2  in  the  packaoo  specification.  Both  xx  and  the  body  of  proc2  are 
hidden  from  other  compilation  units*  preservino  the  semantics  of  the 
orisinal  J73  version. 

The  "overhead"  involved  in  the  creation  of  a  packaoo  for  a  procedure 
with  static  local  data  is  further  Justified  by  the  fact  that  the 
packaoo  structure  solves  another  major  translation  problem  -  that  of 
external  declarations*  discussed  in  the  next  paraoraph. 

The  main  prooram  module  Mill  be  translated  to  a  procedure  or  a  packaoo 
usino  the  same  techniques  as  for  an  ordinary  procedure  module!  Ada 
does  not  require  a  syntactic  distinction  betMeen  stain  and  subordinate 
modules.  Procedures  and  functions  stay  be  nested  in  Ada*  Just  as  in 
J73*  with  no  chanoe  in  prooram  seswntics.  All  Ada  subproorams  are 
compiled  to  be  reentrant  and  recursive*  so  that  the  Translator  • ev 
ionore  the  RENT  and  REC  attributes  in  a  procedure  declaration. 

A  module  containino  multiple  DEF  PROC's  (i.e.«  non-nested  procedures 
and  functions)  will  be  translated  to  a  packaoo  which  contains  multiple 
procedure  or  packaoo  declarations.  For  example*  a  module  such  as 
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START 

"declarations  slobal  to  AAA  and  BBB" 

DEF  PROC  AAAI  "procedure  with  tom*  DEF  items" 
BEGIN 


END 

DEF  PROC  BBBl  "procedure  with  no  DEF  or  static  date" 
BEGIN 


END 

TERM 


would  become  a  package  specification  whose  name  is  derived  from  the 
two  DEF  PROC's* 

PACKAGE  A A A_BBB_ pack  IS 

declarations  alobal  to  AAA  and  BBB 
PACKAGE  AAA_p*ck  IS 
PROCEDURE  AAA... 


END  AAA.Packl 
PROCEDURE  BBB  IS 


END  BBBl 
END  BBBl 

END  AAA-BBB-Packl 

Machine  specific  functions  and  procedures  are  not  coded  in  J73.  and 
therefore  will  not  be  processed  by  the  Translator.  The  user  may  code 
machine  specific  routines  in  Ada  usinv  the  technique  described  in 
Section  13.8  of  the  Ada  Reference  Manual. 

3.2. 1.2. 2  Externals 

The  J73  REF  and  DEF  constructs  specify  declarations  that  are  used 
externally.  As  previously  stated.  Ada  externals  must  be  declared  in  a 
pack***  specification.  The  only  Ada  construct  that  resembles  the  J73 
REF  is  the  WITH  clause,  which  was  shown  to  be  equivalent  to  the  J73 
compool  directive.  The  WITH  clause  may  be  used  to  translate  J73  REF 
declarations  in  a  similar  manner. 
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A  J73  module  containin*  one  or  more  declarations  that  are  to  be  made 
available  to  external  modules  (e.s.>  DEF  ITEM*  DEF  TABLE,  etc.)  will 
be  translated  into  an  Ada  packase.  The  specification  of  the  packase 
will  contain  all  declarations  which  are  DEF'ed  in  the  J73  version.  If 
the  module  is  a  DEF  PROC,  the  packase  specification  will  include  a 
declaration  of  the  procedure  itself.  If  the  module  is  a  compool,  in 
which  everythin*  is  DEF'ed,  we  have  the  situation  discussed  in 
3.2.1. It  the  whole  module  becomes  a  package  specification  with  no 
body. 

With  all  DEF'ed  objects  declared  in  packase  specifications,  other 
modules  can  REF  the  objects  by  usine  a  WITH  clause.  In  seneral ,  a  J73 
procedure  of  the  form 

START 

DEF  PROC  procnamet 
BEGIN 

"local  declarations  which  are  DEF'ed" 

“other  local  declarations" 

"the  rest  of  the  procedure  body" 

END 

TERM 

will  be  translated  to  an  Ada  package  of  the  form 

PACKAGE  procname-pack  IS 
PROCEDURE  procnamet 

—  local  declarations  which  were  DEF'ed 

END  procname-pack t  —  end  of  package  specification 

PACKAGE  BODY  procname-pack  IS 

—  static  local  declarations 
PROCEDURE  procname  IS 

BEGIN 

—  remainin*  local  declarations 

—  rest  of  procedure  body 

END  procnamet  —  end  of  procedure  body 
END  procname-pack t  —  end  of  packase  body 

so  that  all  objects  which  were  DEF'ed  can  be  accessed  externally 
(REF'ed)  usins  "WITH  procname-pack". 
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A  problem  irises  when  REF  declarations  are  used  in  compools.  REF 
PROC's*  REF  ITEMS*  etc.*  are  sometimes  included  in  compools  as  a  means 
of  copvine  the  REF  declarations  into  other  modules.  If  compool  REF 
declarations  were  translated  to  WITH  clauses*  the  resultin*  Ada 
prosram  would  contain  many  circular  compilation  dependencies.  For 
example*  a  compool  full  of  REF  PROC's  mav  be  imported  bY  all  modules 
which  contain  procedure  calls*  resulting  in 

WITH  PI.  P2*  P3. . .  —  REF's  to  each  procedure 

PACKAGE  ref proccompoo 1  IS 


END  ref proccompool ? 
for  the  compool  and 

WITH  ref proccompool l  —  imports  the  compool 
PACKAGE  PN_pack  IS 


END  IN.packl 

for  each  procedure.  This  is  unacceptable*  since  the  mutual  WITH 
clauses  preclude  any  possible  order  of  compilation  (A  module  must  be 
compiled  after  all  modules  whose  names  appear  in  its  WITH  clause). 
This  problem  is  solved  by  Placine  the  REF  PROC  in  the  module  that 
actually  needs  it*  rather  then  in  the  compool  from  which  the  REF  PROC 
is  imported.  Thus*  a  procedure  which  reads  in  a  REF  PROC  from  a 
compool  will  eet  a  WITH  clause  for  the  REF  PROC.  For  example*  if 
procedure  P22  reads  in  (from  a  compool)  a  REF  of  procedure  P44*  then 
P22  will  eet  the  "WITH  P44"  clause;  the  compool  will  not.  In  eeneral * 
REF  declarations  in  compool s  will  result  in  WITH  clauses  for  the 
compool  itself  only  if  the  REF  is  to  another  compool;  otherwise*  the 
REF  declarations  will  simply  be  removed  from  the  compool  and  placed, 
in  the  form  of  WITH  clauses*  in  modules  which  import  the  compool. 


3. 2. 1 . 3  Summary 

The  functions  performed  by  the  Translator  with  respect  to 
proeram/module  structure  are  summarized  below. 

a.  Compool s  will  be  translated  to  packaee  specifications 
with  no  packaee  body. 

b.  Compool  directives  will  be  translated  to  WITH  clauses  of 
the  form  "WITH  compool -name". 
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c.  Procedures  «nd  functions  which  contain  no  static  or  DEF 
declarations  will  b*  translated  into  Ada  procedure  and 
function  bodies. 

d.  Procedures  and  functions  which  contain  static  or  DEF 
declarations  will  be  translated  into  Ada  packaees  with 
the  following  characteristics! 

the  name  of  the  packaee  will  be  of  the  form 
"procedure-name-pack". 

-  the  packaee  specification  will  contain  all 
declarations  which  are  DEF'ed. 

-  the  packaee  body  will  contain  the  procedure  or 

function  body,  with  non-static  declarations  inside 
the  procedure  < function)  body  and  static 

declarations  outside  the  procedure  (function)  body. 

e.  Modules  containing  REF  declarations  will  be  translated 

to  modules  that  use  WITH  clauses  to  access  externally 
DEF'ed  objects.  For  each  module  whose  external 

declarations  are  needed  (REF'ed).  a  clause  of  the  form 

"WITH  name.of -packaee.c  onta i n 1 ne_ t  he.or i • i na 1 .dec 1 arat i on " 
will  be  placed  before  the  module  headine  (i.e.»  before 
the  package  or  procedure  or  function  declaration).  This 
will  remove  the  need  for  an  explicit  declaration  in 
place  of  the  REFi  the  declaration  will  be  imported  from 
the  module  that  orieinallv  included  it. 

f.  In  the  case  of  REF  declarations  in  compools  which  refer 
to  non-compool  modules,  the  WITH  clause  generated  by  the 
REF  will  appear  in  the  modules  that  import  the  compool. 
rather  than  in  the  compool -packaee  itself. 

A  maJor  implication  of  these  functions  is  that  the  Translator  must 
provide  a  mechanism  for  determining  the  elobal  context  of  names.  F.>r 
example,  the  Translator  must  know  in  what  packaee  an  object  is  DEF'ed 
in  order  to  translate  a  REF  of  that  object.  This  elobal  knowledee  of 
name  context  is  analoeous  to  the  Ada  environment  itself.  The  J73 
environment  maintains  elobal  knowledee  only  of  compool  declarations! 
externals  are  not  resolved  until  the  compiled  modules  are  linked. 
Creatine  a  elobal  data  base  durine  compilation/translation  of  the 
proeram  involves  some  overhead  in  both  time  and  space  for  the 
compiler/translator,  but  the  extra  resources  required  are  considered 
worthwhile  for  two  reasons! 
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a.  Thera  is  no  other  way  to  translate  J73  external 
references  to  cleanly-compilable  Ada  code. 


b. 


The  Ada 
techniques 
"correct" 
semantics! 
usins  the 
visibil itv 
a  eood  Ada 


programs  resulting  from  the  translation 
described  in  this  paraeraph  will  not  onlY  be 
in  the  sense  of  accurately  reflecting  J73 
theY  will  also  be  “wel 1 -structured  Ada." 
concerts  of  packaeine*  data  hidine*  and  name 
in  precisely  the  manner  that  would  be  used  bY 
proerammer. 


The  efficient  implementation  of  the  elobal  data  base  for  name  context 
determination  is  discussed  in  a  later  report. 


3.2.2  Typos  and  Declarations 

This  paraeraph  describes  translation  functions  which  are  related  to 
declaration  and  use  of  types.  variables*  and  constants. 


3.2.2. 1  Predefined  Typos 

Both  J73  and  Ada  feature  predefined  tYres  that  may  be  used  in  a 
declaration  alone  with  ranee  and  Precision  specifiers.  J73  syntax  for 
numerical  and  strine  types  a  kind  of  shorthand  notation*  such 

as 

TYPE  unsiened  U»  "full word  unsiened  inteeer" 

TYPE  halfint  S  8t  "eieht  bit  siened  inteeer" 

ITEM  sixchar  C  61  "six  bYte  character  strine" 

ITEM  wholefrac  A  0*31!  "fixed  point  number  with  no  scale 

bits  and  31  fraction  bits" 

in  which  precision*  ranee*  or  size  of  a  tyre  is  eiven  in  terms  of  the 
number  of  bits  or  bytes  needed  to  represent  values  of  the  tyre.  In 
Ada*  these  attributes  are  specified  in  terms  of  explicit  ranee 
constraints*  fixed  point  "delta"  and  floatine  point  "dietts"  for 
numerical  types,  and  by  arrays  for  strine  types.  The  J73  predefined 
types  <U»S. A.F.C.B)  will  be  translated  to  Ada  type  names  such  as 


J73  TYPE  NAME 


ADA  TYPE  NAME 


U 

U  3 
S  31 
A  5*26 
A  14 
F  27 
C  10 
B  18 


U_tvpe 

U5_type 

S31_type 

A5-.26.type 

A14 _ type 

F27_type 

CIO-type 

B18_type 
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on.  For  each  unique  Ada  type  name  senerated  in  this  manner,  the 
itor  will  senerate  a  declaration  which  will  so  into  a  rackase 
" J73_predef ined_packaae. "  The  contents  of  this 

itoi — senerated  packase  will  be  output  upon  user  request  (see 
!)  . 

itions  in  J73_rredef ined-packase  for  inteser  types  will  be 
translations  of  size  to  ranse.  Examples* 

1TYPE  U-type  IS  INTEGER  RANGE  0. . INTEGER' LAST* 

(TYPE  US-type  IS  INTEGER  RANGE  0. .311 

(TYPE  S31_type  IS  INTEGER  RANGE  -2**31 ..( 2**31 >-l I 

ns  these  types  as  subtypes  of  the  predefined  type  INTEGER  will 
that  implicit  type  conversion  will  be  made  between  any  two 
types,  as  in  J73.  If  new  types  were  declared,  rather  than 
'S.  implicit  conversions  would  not  occur!  Ada  treats  distinctly 
?d  types  as  non-matchins  types,  even  if  the  types  are  declared 
ally. 

►oint  types  require  a  specification  of  "delta”,  the  error  bound, 
is  eeual  to  2**<-F)  for  a  J73  fraction  size  of  F.  Thus,  a 
m  size  of  4  will  yield  a  delta  of  1/161  a  fraction  size  of  -6 
eld  a  delta  of  256.  The  ranse  of  a  fixed  point  type  is  computed 
■1y  to  that  of  sisned  intesers.  Examples* 

A5_26_type  IS  DELTA  1.0/2**26  RANGE  -2**5. . (2**5)- ( 1.0/2**261 1 

s  better  coded  as 

_5>26i  CONSTANT  *-  1.0/2**261 

E  A5_26_tYP*  IS  DELTA  del.5-26  RANGE  -32. . 32-del _5-26l 
example* 

_ 1 4 _ I  CONSTANT  *-  1 . 0/2**(W0RD_LENGTH-15> l 

E  A14 _ type  IS  DELTA  del _14__  RANGE  -2**14. .  2**  14-del  _1 4—1 

e  scale  and  fraction  specifiers  are  handled  in  the  same  manner, 
ype  "A  -6.37"  will  yield 

6-37!  CONSTANT!  ■  1.0/2**371 

An6_37  IS  DELTA  del_n6_37  RANGE  -1 . 0/2**6. . 1 .0/2**6-del _n6_37l 

declares  a  fixed  point  fraction  type  whose  values  are  between 
nd  (about)  1/64  with  31  bits  of  precision. 
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Unfortunate! y.  there  can  be  no  predefined  fixed  point  type  from  which 
all  needed  types  can  be  "subtyped" *  as  with  integers.  The  reason  for 
this  is  the  rule  that  the  values  of  all  subtypes  must  be  subsets  of 
the  values  of  the  parent  type.  The  values  of  all  possible  fixed  point 
types  are  not  subsets  of  any  Ada-definable  type.  Therefore*  fixed 
point  types  will  be  distinct  types*  and  any  J73  implicit  type 
conversions  will  be  translated  to  explicit  Ada  type  conversions. 

Floating  point  types  require  accuracy  specification  in  terms  of  the 
number  of  decimal  disits.  For  B  bits  of  precision  in  the  mantissa*  the 
number  of  decimal  disits  needed  for  esual  precision  is 


e 

B/los  10 
2 


Examples  of  floating  point  type  declarations! 

SUBTYPE  F.type  IS  FLOAT l 

SUBTYPE  F27_type  IS  FLOAT  DIGITS  8? 

An  Ada  compiler  will  venerate  floating  point  code  with  at  least  the 
precision  specified  in  the  type  declarations!  this  is  identical  to  J73 
semantics  for  floatin*  point  arithmetic.  Implicit  type  conversions 
between  objects  of  floatin*  point  types  will  work  the  same  way  as 
previously  described  for  inteser  types. 


All  of  the  preceedin*  examples  assume  a  two's-compl ement  tar*et 
machine.  The  ranse  specification  needed  for  integers  and  fixed  point 
numbers  would  be  different  for  a  one's-compl ement  (or  sisn-ma*nitude ) 
tar*et  in  that  the  lower  bound  is  one  “error  bound"  closer  to  zero.  In 
9enera1 >  for  a  precision  or  scale  size  of  B  bits*  the  lower  bounds  of 
sisned  inteser  and  fixed  point  types  are 


sisned  inteser 


fixed  point 


two's  complement!  -<2**B> 

one's  comp/sisn  mast  -<2**B)+1 


-<2*#B)+delta 


The  upper  ranse  bounds  are  the  same  for 
<<2**B-1)  for  sisned  inteser*  (2**B-delta) 
Translator  will  select  lower  bounds  based 
desired  tarset  machine  representation. 


either  representation 
for  fixed  point).  The 
on  a  TPF  entry  for  the 


The  actual  number  of  disits  will*  of  course*  be  the  least  inteser 
sreater  than  this  quantity. 
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J73  character  types  may  be  represented  a*  Ada  strina  types.  such  as 

SUBTYPE  C_10_type  IS  STRING ( 1  . . 10) t 
SUBTYPE  C-tYM  IS  STRING(  1 .  .  1 ) ! 

so  that  objects  of  character  type  will  be  accessible  as  arrays.  This 
permits  both  access  to  the  entire  object  and  access  to  a  substring  of 
the  object  (usina  a  slice*  its  name  followed  by  a  ranae 
specification),  allowins  straiahtf oward  translations  of  J73  type 
conversions  and  byte  operations. 

The  remainina  J73  predefined  type.  bit  type.  is  the  most 
problematical.  Ada  includes  a  boolean  type  which  corresponds  to  the 
J73  type.  "B  1".  but  contains  nothina  equivalent  to  a  bit  strina  type. 
Two  possible  translations  involve  the  use  of  inteaer  types  and  array 
types. 


Objects  of  inteaer  type  are  unsuitable  for  representation  of  bit 
strinas  for  two  reasons.  First,  the  maximum  allowed  size  of  an  inteaer 
in  •  typical  Ada  implementation  will  be  one  or  two  taraet  words  <16-64 
bit*),  while  J73  bit  strinas  may  be  dozens  of  taraet  words  in  lenath. 
Thus.  Iona  bit  strinas  such  as  MB  256"  would  be  unmarpable  into  Ada 
inteaers.  The  second  problem  involves  boolean  operations.  Since  Ada 
permits  only  boolean  arauments  to  operators  such  as  "and",  "or", 
"not",  and  "xor".  performins  such  operations  on  inteaers  would  require 
the  equivalent  of  overloadins  of  the  operators  for  the  types  in 
question.  Conversion  of  inteaer  types  to  boolean  or  array  types  is 
illesal*  the  implementation  of  boolean  operations  on  inteaers  would  be 
awkward  and  inefficient. 

A  workable  translation  of  J73  bit  types  uses  arrays  of  booleans. 
J73_predef ined-packaae  will  include  the  declaration 

TYPE  bit-strina  IS  ARRAY  < INTEGER  RANGE  <  >)  OF  BOOLEAN* 

to  establish  a  parent  type  for  specific  subtypes  such  as 

SUBTYPE  B_18_type  IS  bit.strina  <0..17)l 
SUBTYPE  B256_type  IS  bit-strina  (0..255)* 

and.  for  consistency. 

SUBTYPE  Bl.type  IS  bit-strina  (0..0M 
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This  i ns  will  permit  bit  strinss  to  be  accessed  in  the  seme  manner 

as  character  strines>  usins  "slice"  references  for  type  conversions 
and  substring  operations  (e.e.>  the  J73  "bit"  operator).  The  Ada 
boolean  operators  are  directly  applicable  to  boolean  array  types,  so 
that  no  inefficiency  will  be  incurred  in  performing  boolean 
operations.  The  only  remainin*  problem  is  /storase  efficiency?  J73  bit 
strinss  are  always  packed,  while  Ada  arrays  are  not.  This  problem  is 
solved  by  including 

PRAGMA  PACK  < bi t_str ins ) I 

in  J73_predef ined-packase*  which  requests  the  Ada  compiler  to  pack  all 
arrays  of  type  bit.strins  to  minimize  space. 


3. 2. 2. 2  Type  and  Object  Declarations 

Translation  of  type,  variable,  and  constant  declarations  in  J73  will 
be  translated  to  Ada  declarations  usins  the  predefined  types  discussed 
in  the  preceedins  parasraph  whenever  possible.  Declarations  which 
cannot  make  use  of  the  predefined  types  will  use  distinct  type 
definitions  as  necessary.  The  followins  parasraphs  discuss  the 
translation  of  each  kind  of  J73  type  and  object  declaration  in  the 
order  eivem 

a.  Scalar  (numeric,  strins.  and  enumeration)  types 

b.  Tables 

c.  Pointers 

d.  Other  (blocks,  defines,  etc.) 


3. 2. 2. 2.1  Scalar  Types 

Declarations  of  types  and  objects  of  numeric  or  strine  types  will  be 
translated  usins  the  predefined  types  declared  in 
J73-predef i ned-pac  kase . 

Examples? 

ITEM  speed  U  10! 

CONSTANT  ITEM  Pi  A  2.15  -  3.14159? 

TYPE  name  C  13? 

ITEM  mask  STATIC  B  36  -  4B ' 800000000 ' ! 
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will  be  translated  to 
speed*  U10_tvpe! 

pi*  CONSTANT  A2_ 15-type* -3. 141591 

SUBTYPE  name  IS  C13_tyrel 

mask!  B36_t vre * « ( 0->TRUE ,  1 . . 35«>FALSE ) I 

The  translations  of  the  first  three  of  thasa  declarations  are 
straishtfoward  uses  of  types  (subtypes)  declared  in 
J73_predef ined.packase.  The  fourth  declaration  involves  two  additional 
features*  the  STATIC  specifier  and  a  preset  value.  Translation  of 
static  declarations  involves  the  context  of  the  declarations,  as 
described  in  3.2. 1.2. 1.  Translation  of  the  preset  of  the  bit  strinw 
requires  convertins  a  J73  bit  constant  to  a  corresponding  Ada 
assresate.  In  this  example,  the  J73  literal  whose  first  bit  is  a  "1" 
and  whose  remainins  bits  are  "0H  becomes  an  assresate  whose  zero 
position  has  a  value  of  TRUE  and  whose  first  throush  39th  positions 
have  values  of  FALSE.  This  assresate  has  the  effect  of  initial izins 
each  component  of  the  34  component  array.  Just  as  the  literal. 
4B' 800000000'.  initialized  each  bit  of  the  36  bit  item  in  the  J73 
version.  The  assresate  could  be  written  eeuivalentlv  as'  ( 0">TRUE . 
OTHERS»>FALSE ) »  with  exactly  the  same  effect. 

Round-or-truncate  attributes  in  numerical  declarations  will  not  affect 
the  translation  of  the  declarations  themselves.  However,  conversions 
to  inteser  and  fixed  point  types,  as  well  as  assisnments  to  floatins 
point  types  will,  if  required,  senerate  function  calls  to  user 
supplied  routines  which  will  perform  the  desired  roundins  or 
truncation.  These  function  calls  may  be  suppressed  usins  a  TPF  entry. 

Enumeration  types  are  easily  translated.  For  example,  the  declarations 

TYPE  color  STATUS  <V<red>.  V(amber),  V(sreen))! 

ITEM  sisnal  color! 

CONSTANT  ITEM  storlisht  color  -  V(red)f 

will  be  translated  to 

TYPE  color  IS  (red.  amber,  sreen)! 
sisnal*  color! 

stoplight!  CONSTANT  color*=redl 

Removal  of  the  letter  "V"  and  the  parentheses  from  status  constants 
may  cause  ambiguity  in  the  resulting  translation.  Since  other 
identifiers  in  the  module  containing  the  declaration  of  "color"  may  be 
spelled  the  same  way  as  "red",  "green”,  or  "amber",  dotted  notation 
(e.g..  color. red)  will  be  used  to  translate  references  to  these 
values. 
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Item  declarations  which  include  a  status  list  definition*  such  as 

ITEM  condition  STATUS  (V(»ood),  V(bad))? 

will  be  broken  into  two  declarations: 

TYPE  condition-type  IS  (eood,bad)l 
condition:  condition-type. 

This  is  necessary  because  an  Ada  object  declaration  must  contain  a 
type  (subtype)  name  rather  than  a  type  (subtype)  definition. 

Status  type  declarations  with  specified  representation  attributes  will 
be  translated  usine  Ada  representation  specifications.  A  declaration 
such  as 

TYPE  points  STATUS  3(1  V(pointaf ter ) ,  2  V( safety), 

3  V( f iel dsoal ) ,  6  V( touchdown )) ? 

will  yield  a  basic  type  declaration  and  two  representation 
specifications: 

TYPE  points  IS  (pointafter,  safety,  fieldeoal,  touchdown): 

FOR  eoints'SIZE  USE  31 

FOR  points  USE  ( Pointaf ter»>l ,  safety»>2, 

f ieldeoal->3,  touchdown»>6> : 

This  technique  will  assure  proper  representation  of  values  of  the 
status  type. 


3. 2. 2. 2.2  Tables 

A  J73  table  is  an  aeereeate  data  object.  The  simplest  form  of  a  table 
declaration  includes  a  name,  a  dimension  list,  and  an  item  t"\  pe 
description,  such  as 

TABLE  employees  (99)  C  131 
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which  declores  on  trriY  of  100  chorocter  strin*  elements  (indexed  O 
through  99).  This  is  eeuivolent  to 

empl oyoosi  ARRAY  (0. .99)  OF  C13_tYPel 

Tobies  bodies  correspond  to  records.  A  seriol  toblo  will  b#  tronslotod 
in  two  ports.  First*  o  record  typo  will  bo  doclorod  to  notch  tho  toblo 
body.  Socond*  on  orroy  of  rocord  typo  will  bo  doclorod  to  motch  tho 
toblo  nono  ond  dinonsion  list.  For  exomple*  o  toblo  contoinin* 
employee  infornotion  doclorod  os 

TABLE  omrIOYOOs  (99) I 
BEGIN 

ITEM  nomo  C  151 

ITEM  ronk  ronktypof  "ronktypo  is  doclorod  olsowhoro" 

ITEM  soriolnumbor  U» 

END 

will  bo  tronslotod  to 

TYPE  onpl 0Y00S_tYP0  IS 

RECORD  — doc loros  tho  typo  of  tho  toblo  body 

nornoi  C13_typol 
ronkt  ronktypol 
soriolnumbor*  U.typol 
END  RECORD I 

oiapIoyoos*  ARRAY  <0.  .99)  OF  omrl OYoos-typo*  — docloros  tho  toblo 

Tho  tronslotion  is  dono  in  two  ports  bocouso  on  Ado  orroy  doclorotion 
must  uso  o  typo  nomo  rothor  thon  o  typo  description.  Toblos  with  moro 
thon  ono  dimension  will  become  orroys  of  moro  thon  one  dimension! 

TABLE  multidim  (22*  14H14,  511)... 

becomes 

multidimi  ARRAY  (0. . 22. 14. . 1 14*0. . 51 1 ) . . . 

Pock in*  specifiers,  words-per-entry*  ond  locotion  specifiers  will  bo 
tronslotod  by  moons  of  roprosontotion  specif icotions.  If  tho  toblo 
"empl oyoos"  wore  doclorod  os  o  specified  toblo* 


1 
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TABLE  amrlovaas  <9?>  W  6* 

BEGIN 

ITEM  nama  C  15  POS<e.O)i 
ITEM  rank  ranktyra  P0S<0»4)1 
ITEM  sarialnumbar  U  POS(l . 5)1 

END 

its  translation  will  consist  of  tha  racord  and  array  daclarations 
sivan  aarliar  and  tha  rarrasantation  sraci f ication 

FOR  amrloyaas  USE 

RECORD  AT  MOD  6*wordl  — six  words  rar  antry 

nama  AT  0*word  RANGE  S. .1271  — ransa  axtands  to  adJacant 

— words 

rank  AT  4*word  RANGE  O. .311 
sarialnumbar  AT  5*word  RANGE  1..31! 

END  RECORD 1 

whara  "word"  is  a  constant  arual  to  tha  numbar  of  storava  units  par 
taraat  word.  A  variabla-lanath-antry  specif iad  tabla  will  yiald  tha 
alignment  clausa*  "AT  MOD  1*  word".  Ordinary  tablas  with  medium  or 
dansa  packino  will  ba  translatad  usino  tha  locations  of  aach  component 
salactad  to  conform  to  J73  samantics  of  tha  packino  spacifiars  usad. 
Tioht  tablas  will  ba  affactad  by  usa  of  tha  rraama.  "pack". 

Tha  pracaadino  discussion  has  dascribad  tha  translation  of  sarial 
tablas  to  arrays  of  racords.  A  rarallal  tabla  will  ba  translatad  to  a 
racord  of  arrays.  Tha  tyra  of  aach  of  thasa  arrays  will  ba  a  racord 
that  is  praviously  daclarad  to  includa  tabla  itam  daclarations  oroupad 
accordino  to  antry  word.  Tha  oanaral  format  of  this  translation  is 
oivan  as  follows*  a  rarallal  tabla  daclaration 

TABLE  tt  (44)  PARALLEL... 

BEGIN 

"daclarations  of  itams  positioned  in  word  O" 

"daclarations  of  itams  rositionad  in  word  1" 


END 

will  ba  translatad  to  tha  followin*  daclarations' 
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TYPE  tt_word_0_type  IS 
RECORD 

—-declarations  of  objects  positioned  in  word  O 
END  RECORD I 

TYPE  tt_word_l_tYPe  IS 
RECORD 

— -decl orations  of  objects  positioned  in  word  1 
END  RECORD! 


TYPE  tt-type  IS  — *  "record-of-arrays"  type 

RECORD 

tt-word_0i  ARRAY (O. .44)  OF  tt_word_0_type! 
tt_word_l i  ARRAY (0. .44)  OF  tt_word_ l_tvpe! 


END  RECORD! 

ttftt_type!  — declares  a  record  object 

Grouri n*  the  objects  of  each  entry  word  in  a  separate  record  permits 
translation  of  parallel  tables  with  specified  entries  usine 
representation  specifications  for  each  r*cord.  including  the 
positioning  of  several  items  per  entry  word.  An  ordinary  table  with 
parallel  structure  will  not  require  these  separate  record  type 
declarations  for  each  entry  word!  it  is  completely  described  by  a 
sinele  record.  For  example,  the  table 

TABLE  ordinary  <441  PARALLEL! 

BEGIN 

ITEM  aa  A  0.31! 

ITEM  bb  S  ! 

ITEM  cc  C  4! 

END 

will  become 

TYPE  ©rdinery_tYPe  IS 
RECORD 

aa i ARRAY  <0. .44)  OF  A0_31.type! 
bbi ARRAY  (0..44)  OF  S_type! 
cc i ARRAY  (0. .44)  OF  C4_type! 

END  RECORD! 

ordinary!  ordinary_type! 
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Table  presets  end  table  item  presets  will  be  translated  usins 
aeereeate  values  as  described  for  strine  presets  in  3. 2. 2. 2.1.  The 
"like"  option  will  result  in  records  which  include  reference  to 
previously  declared  records  as  appropriate.  Star-bound  tables  will  be 
declared  usine  unconstrained  arrays  < "ARRAY <<>>"> . 

There  is  a  special  case  in  which  specified  table  declarations  will  not 
be  completely  translated.  J73  table  items  may  overlap  in  bit  position 
within  a  table  entry.  This  proeremmine  technique  is  sometimes  used  to 
define  mask  fields  and  substrings  of  table  data.  Under  the  translation 
outlined  in  this  paraeraph.  overlapping  table  items  would  be 
translated  to  incorrect  Ada  code*  since  locations  specified  by  a 
representation  specification  within  a  record  must  not  overlap.  The 
exception  to  this  rule  is  that  storaee  for  distinct  variants  of  a 
record  may  overlap.  However»  this  requires  that  the  discriminants  be 
static,  prohibiting  dynamic  selection  of  variant  objects.  Thus, 
variant  records  will  not  be  used,  nor  does  any  other  Ada  construct 
appear  adequate  for  this  mappine.  The  Translator  will  detect  table 
item  overlaps.  translate  them  as  (illegally)  specified  records,  and 
output  a  warnine  messaee  to  inform  the  user  of  the  need  to  reproeram. 


3. 2. 2. 2. 3  Pointers 

J73  pointer  types  will  be  translated  to  Ada  access  types.  The 
translation  is  euite  simple  for  typed  pointers. 

TYPE  link  P  celll 

becomes 

TYPE  link  IS  ACCESS  celll 


and 


ITEM  symrtr  P  symtabi 

is  translated  to  the  pair  of  declarations. 

TYPE  symptr-tYPe  IS  ACCESS  symtabi 
symptri  symptr_typel 

This  permits  an  access  of  a  pointed-to  variable  such  as 
"var iable®symrtr"  to  be  translated  to  "symptr. variable". 
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of  untv^d  pointers  is  more  difficult,  because  Ada  does 
not  permit  anonymous  access  types.  The  Translator  must  Perform  a 

!  0b:  ifr  i,i,i  V  th*  Pr09r*m  t0  d*t#rmine  the  types  of  all  objects 
to  which  The  pointer  may  point.  If  the  Pointer  is  used  for  objects  of 

tYr *’  th#  yr*n#1*tor  “in  simply  "type"  the  Pointer  in  its 
declaration.  For  example,  a  table  containine  an  untyped  pointer 

TABLE  cell  (49)? 

BEGIN 

ITEM  value  val_type? 

ITEM  next  P?  "next  is 
END 


used  to  point  to  other  cells" 


will  be  translated  to 


—incomplete  type  declaration 
TYPE  next-type  IS  ACCESS  cell -type? 

TYPE  cell -type  IS 
RECORD 

value?  val-type? 
next:  next-type? 

END  RECORD? 
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cell*  ARRAY  <0. .  49)  OF  ctll.tYMl 

If  the  pointer  is  used  for  objects  of  several  types,  the  Translator 
will  select  a  type  for  the  pointer  according  to  frequency  of  use.  For 
example.  if  an  item  declared  as  an  untyped  pointer  is  most  often  used 
to  point  to  objects  of  type  "cel  1 2_type" .  then 

ITEM  pointanywhere  Pi  "usually  points  to  cell2_type" 

will  be  translated  to 

TYPE  pointanywhere_type  IS  ACCESS  cell2_typel 
pointanywhere J  po i n tan ywhere_ type . 

with  an  incomplete  declaration  of  cell2_type  included  (if  necessary) 
before  the  declaration  of  Pointanywhere_type.  References  to 
pointanywhere  will  need  type  conversions  only  if  the  target  type  is 
not  cell2_tvpe?  conversions  to  ce!12_tvpe  will  be  deleted  by  the 
Translator,  since  they  are  unnecessary. 


3. 2. 2. 2. 4  Other  Declarations 

Block  declarations  are  used  to  declare  groups  of  items,  tables,  and 
other  blocks  which  are  to  be  stored  contiguous  1 y.  Although  no  Ada 
construct  provides  contiguous  storage  allocation,  blocks  will  be 
translated  to  records,  providing  access  to  blocks  (including  parameter 
passing)  in  a  manner  which  is  semantically  similar  to  J73.  In  general, 
a  block  declaration  of  the  form 
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BLOCK  dataeroupl 
BEGIN 

"sequence  of  declarations " 

END 

will  be  translated  to 

TYPE  datasroup_tvee  IS 
RECORD 

— sequence  of  declarations 
END  RECORD 1 

datasroupt  data*roup_tvpe; 

alone  with  a  warnine  messaee  to  inform  the  user  that  the  objects 
declared  in  the  block/record  may  not  have  contiguous  stora.se 
al 1 ocation. 

Statement  name  declarations  are  used  to  declare  labels  which  are  to  be 
used  as  formal  parameters.  Since  the  Translator  will  not  translate 
label  parameters.  these  declarations  will  not  be  translated  (see 
3.2. 3. 3). 


Define  declarations  are  used  to  achieve  parameterized  compile-time 
strins  substitution  <i.e.»  macro-expansion).  Define  declarations  which 
correspond  to  simple  constants  will  be  translated  to  constant 
declarations.  For  example. 

DEFINE  upperbound  "2**15-1"! 

will  be  translated  to 

upperboundi  CONSTANT**  2**15-11 

Other  define  declarations.  in  seneral .  have  no  Ada  equivalent.  The 
Translator  will  simply  expand  define  calls  in  the  J73  module  before 
translation.  The  user  may  request  a  summary  of  define  expansions 
performed  as  a  translation  option. 

Although  Ada  contains  no  construct  for  overlaying  data,  an  Ada 
implementation  may  provide  a  prasma  for  this  purpose.  The  overlay 
declaration  will  be  translated  usin*  this  prasma  if  it  is  available! 
otherwise,  overlay  declarations  will  not  be  translated. 

J73  allows  null  declarations  whose  syntactic  form  is  either  a 
semicolon  or  an  empty  BEGIN-END  bracket.  These  declarations  will  be 
translated  to  the  Ada  construct.  NULL. 


F-31 


JOVIAL  TO  ADA  TRANSLATOR  INVESTIGATION 
FUNCTIONAL  DESCRIPTION 


3.2.3  Executable  Constructs 

This  paragraph  describes  the  translation  functions  associated  with 
formulas,  expressions,  and  statements.  The  discussion  is  given  in 
three  parts: 

a.  Expressions,  formulas,  and  assignment  statements. 

b.  Local  control  statements. 

c.  Procedure  and  function  call  statements  and  return 
statements. 

Special  executable  constructs  known  as  intrinsic  functions  are 
discussed  in  3.2.5. 


3;'2,.3.1  Expressions  and  Assignments 

In  general.  arithmetic  formulas  such  as  ( ( AA*BB-CC > **2 )  will  be 
unchanged  by  the  Translator.  Each  arithmetic  operator  of  J73  has  an 
Ada  equivalent  with  the  same  form  and  precedence.  Ada  distinguishes 
between  binary  and  unVv  uses  of  the  operators  "+"  and  giving 

higher  precedence  to  unary  occurrences,  but  in  practice  this  does  not 
affect  the  results  of  an  arithmetic ^formula.  (J73  treats  unary  "+"  and 
as  "signs"  rather  than  operators,  so  that  expressions  such  as 
<5 — 3)  must  be  written  as  <5-<-3))»  removOr*  the  need  for  a  precedence 
distinction.)  Type  qualifiers  wifi  be  inserted  into  fixed  point 
expressions  when  needed,  as  discussed  in  3.2.2. 1. 

Status.  table.  character.  and  pointer  formulas  do  not  involve 
operators.  and  will  not  be  changed  by  the  Translator.  Bit  formulas  in 
J73  are  required  to  include  parentheses  whenever  more  than  one  kind  of 
operator  is  used,  so  that  precedence  is  irrelevant.  The  EQV  operator 
will  be  translated  to  "■"»  which  is  overloaded  in  Ada  to  include 
boolean  expressions.  The  AND  and  OR  operators,  when  used  in  boolean 
formulas  (bit  formulas  of  type  B1 ) .  will  be  translated  to  the  short 
circuit  forms.  AND  THEN  and  OR  ELSE.  corresponding  to  the  J73 
semantics  for  boolean  formulas!  bit  formulas  of  size  greater  than  one 
will  use  the  standard  AND  and  OR  forms. 

Relational  operators  are  equivalent  in  J73  and  Ada.  The  "not  equal" 
operator  in  J73  <"<>">  will  be  converted  to  its  Ada  equivalent.  "/«". 
All  relational  operators  have  equal  precedence  in  both  languages. 

Type  conversions  in  Ada  are  permitted  only  between  closely  related 
types.  so  that  conversions  of  numeric  types  to  numeric  types,  bit 
types  to  bit  types.  character  types  to  character  types,  and  table 
types  to  table  types  may  be  translated  directly.  For  example. 
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lintever(xx)  "xx  is  a  halfword  intever" 

5.26  *)yy  "yy  is  tYM  A  0.31" 

translated  to 

I  integer  (xx) 

J6-tvpe  (yy) 

ions  between  unrelated  tYPes  (such  as  character  to  intever)  and 
ions  involving  pointers,  status  objects,  and  the  REP  function 
be  performed  directlY  in  Ada.  The  onW  Ada  construct  available 
ich  conversions  is  the  predefined  eeneric  function. 
ID-CONVERSION.  Instantiations  of  this  eeneric  will  appear  in 
tef ined_packaee  for  each  kind  of  conversion  which  has  no  direct 
ivalent.  The  J73  conversions 

8*) name  "name  is  of  tYpe  Cl" 

! xyz )  "xyz  is  of  tYpe  F" 

i e2 ( #po i nt )  "point  is  of  type  P  tablel" 

:ause  the  followine  instantiations  to  be  included  in 
lef i ned-packase « 

;TI0N  Cl_tYPe_conversion  IS  NEW  UNCHECKED-CONVERSION  (Cl-tYPe)l 
:TION  F_tYPe_conversion  IS  NEW  UNCHECKED-CONVERSION  (F_tYPe>l 
;TIGN  tablel-tYPe_conversion  IS  NEW  UNCHECKED-CONVERSION 
>lel_tYPe)  J 

the  tYpe  conversions  m»Y  be  translated  to  the  function  calls 

YPe_conversion( name ) 
pe.conver s i on ( xyz ) 
el_tYPe_conversion(point.al 1 ) 

anslation  technique  will  work  correctlY  onlv  if  the  Ada 
tation  be  ins  used  permits  the  unchecked  conversions  venerated 
Translator.  In  J73.  conversions  between  unrelated  tYPes  are 
ned  bY  compile-time  rules,  while  Ada  does  not  specifY  what 
ill  be  used  bY  a  compiler  in  perf orminv  •  ( or  reJectinv)  such 
ons.  For  anY  unchecked  conversion  which  is  not  allowed  bv  the 
mpiler.  the  user  must  replace  the  instantiation  of 
D-CONVERSION  with  a  customized  function  that  emulates  the 
ndinv  J73  rules  for  the  conversion. 
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Assignment  statements  will  be  translated  by  replacing  the  with  its 

Ada  equivalent?  Assignments  to  more  than  one  variable  in  a 

single  statement?  such  as 

varl?  var2?  var3  =  var2  +  6i 

will  be  broken  into  separate  assignments? 

temps =  var2  +  61 
varl:=  temp? 
var2s  =  temp? 
var3s=  temp! 

using  a  temporary  variable  to  conform  to  the  J73  rule  that  the  right 
hand  side  be  evaluated  only  once. 

To  a  small  extent?  J73  programs  may  rely  on  the  side  effects  of  the 
order  of  evaluation  of  expressions  and  assignments.  The  language 
guarantees  that  the  right-hand  side  of  an  assignment  statement  will  be 
evaluated  before  the  left-hand  side?  and  that  function  arguments  and 
table  indices  will  be  evaluated  1 ef t-to-r ight  before  any  expressions 
or  assignments  are  performed.  Dependence  on  side  effects  of  these 
evaluations?  while  generally  considered  poor  programming  practice?  is 
possible  in  J73.  However?  Ada  gives  no  such  guarantees  regarding  order 
of  evaluation;  a  program  which  contains  such  side  effect  dependencies 
may  be  translated  to  an  erroneous  Ada  program.  The  user  is  responsible 
for  detecting  and  removing  these  dependencies. 


3. 2. 3. 2  Local  Control  Statements 

This  paragraph  describes  the  translation  of  statements  which  affect  a 
program's  flow  of  control  on  a  local  basis.  Global  control  constructs 
(call  and  return)  are  discussed  in  the  following  paragraph. 

The  syntax  of  J73  loop  statements  is  relatively  complex.  A  loop 
statement  may  contain?  in  addition  to  a  loop  parameter  and  a  while 
clause?  a  by-phrase?  a  then-phrase?  and  an  initial  value.  Futhermore? 
the  loop  parameter  may  be  either  a  global  program  variable  or  an 
implicitly  declared  object  which  is  local  to  the  loop  and  unaccessible 
outside  of  the  loop.  By  comparison?  Ada  loops  are  quite  simple.  They 
may  contain  an  implicitly  declared  loop  parameter?  a  discrete  range 
for  the  parameter?  and  a  while-clause;  global  loop  parameters  and 
explicit  by-  or  then-clauses  are  not  permitted.  Translation  of  loop 
statements  is  a  rare  instance  of  mapping  a  complex  J73  structure  onto 
a  simpler  Ada  structure. 
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Loop  statements  with  no  loop  parameter  are  easily  translated.  In 
seneral »  a  loop  of  the  form 

WHILE  bool eanf ormul at 
BEGIN 


END* 


will  be  translated  to 

WHILE  bool eanf ormul a 
LOOP 


END  LOOP? 

A  loop  with  an  implicitly  declared  loop  parameter  (a  ''control-letter” ) 
will  be  translated  usine  an  iteration  clause  (FOR  1 oop_peremeter  IN 
ranse)  whenever  the  by-clause  or  then-clause  corresponds  to  a  loop 
parameter  increment  of  +1  or  -1.  For  example. 

FOR  isO  BY  1  WHILE  iClOOS 


becomes 


FOR  i  IN  0..99 
LOOP 


END  LOOPS 


and 


FOR  is 22  THEN  < i  — 1 >  WHILE  i>»Os 


becomes 

FOR  i  IN  REVERSE  0..22*  • 
LOOP 


END  LOOPS 
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A  loo*  with  a  control  letter  but  no  by-clause.  then-clause.  or 
while-clause  can  be  translated  without  an  iteration  clause: 

FOR  i : 1 : 

BEGIN 


END 

will  be  translated  to  an  Ada  block  with  a  declarative  part 

DECLARE  — block  for  loop  statement 

i:  INTEGER:  »H 
BEGIN 
LOOP 


END  LOOPI 

END:  — block  for  loop  statement 

ensuring  that  the  loop  parameter  is  local  to  the  loop  statement.  A 
similar  loop  with  a  elobal  variable  rather  than  a  control  letter,  such 
as 


FOR  eventcount:  v< f i r stevent ) 1 
BEGIN 


END 

will  be  translated,  without  a  block  or  declarative  part,  to 

eventcount: “fir stevent: 

LOOP 


■ 

END  LOOP: 

since  the  loop  parameter  is  already  declared  elobal  to  the  loop 
statement. 
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Loop  statements  with  global  variable  loop  parameters  and  by-clauses* 
then-clauses*  or  while-clauses*  as  well  as  loops  with  control  letters 
and  increments  not  eeual  to  +  1  or  -1*  will  be  translated  to  Ada 
structures  consistine  of  assignment  statements  and  while-loops.  For 
example*  the  loop 

FOR  aaibb  BY  cc  WHILE  dd>eef  "aa* bb. cc * dd. e«  are  global" 

BEGIN 


END 


will  be  translated  to 

aa<  =bb  5 
WHILE  dd>ee 
LOOP 


aat-aa+cc? 

END  LOOP? 

which  is  not  only  semantically  identical  to  the  J73  form,  but  should 
also  run  Just  as  efficiently.  Another  example? 

FOR  i  ?  bb  BY  cc  WHILE  iOOi  "i  is  a  control  letter" 

BEGIN 


END 


is  translated  to  a  block  with  a  local  declaration  of  it 

DECLARE  — block  for  loop  statement 
it  INTEGER? -bbt 
BEGIN 

WHILE  i/-0 
LOOP 


e 

it-i+cc? 

END  LOOP? 

END?  — block  for  loop  statement 
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The  exit  statement  in  J73  is  directly  mappable  to  Ada.  In  seneral » 
exit  statements  will  be  unchanged  6y  the  Translator.  A  construct  such 
as 


WHILE  condition!? 
BEGIN 


IF  condition2s 
EXITS 


END 


may  be  translated  to 

WHILE  conditionl 
LOOP 


IF  condition2  THEN 
EXITS 
END  IFS 


END  LOOPS 


or.  more  cleanly. 


WHILE  conditionl 
LOOP 


EXIT  WHEN  condition2S 


■ 

END  LOOPS 

Selection  of  the  latter  translation  technique  is  an  optimization  that 
may  be  requested  by  the  user  as  an  option. 

J73  IF  statements  translate  straiehtf orwardl y»  differing  from  Ada  IF 
statements  in  that  the  reserved  word  "THEN"  must  precede  the  body  of 
the  statement.  Therefore. 
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IF  condition* 

"»nv  statement" 

is  translated  to 

IF  condition  THEN 

— sequence  of  statements 
END  IF* 

A  complex  IF  statement  such  as 

IF  conditionl* 

BEGIN 


END 

ELSE  IF  condition2* 


ELSE 


mill  be  translated  usine  the  ELSIF  construct  to 
IF  conditionl  THEN 


ELSIF  condi tion2  THEN 


ELSE 


END  IF* 


Case  statements  are  also  euite  easily  translated* 
"(case-index*...)*"  replaced  by  "WHEN  case-index  I . . 


with  the  construct 
■>".  For  example* 
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CASE  expression* 
BEGIN 

<0, 1): 

(2*4,3): 

(5)* 

(DEFAULT)* 

(9,11)* 

END 


"statementl" 

"statement2" 

"statements" 

"statement4" 

"statements" 


is  translated  to 


CASE  expression  IS 
WHEN  0..1*> 
WHEN  2.. 4! 30 
WHEN  5-> 

WHEN  91110 
WHEN  OTHERS  O 
END  CASE* 


— statement  1 
— statement2 
— statements 
— statements 
— statement4 


The  default  case  alternative  is  moved  to  the  end  of  the  statement,  as 
is  required  in  Ada.  The  FALLTHRU  construct,  which  causes  case 
alternatives  to  be  executed  sequentially,  has  no  Ada  equivalent*  each 
appearance  of  FALLTHRU  will  cause  the  statements  of  the  following  case 
alternative  to  be  duplicated  at  the  end  of  the  case  alternative  which 
contained  the  FALLTHRU. 

The  final  statement  discussed  in  this  paragraph*  the  GOTO  statement, 
will  be  unchanged  bv  the  translator.  The  resulting  Ada  prosram  will  be 
correct  as  Ions  as  none  of  the  GOTO's  cause  a  transfer  of  control  into 
an  if  statement  or  a  case  statement.  J73  permits  such  transfers,  while 
Ada  does  not.  The  Translator  will  detect  and  flas  such  GOTO's, 
informing  the  user  of  the  need  to  restructure  the  module. 


3. 2. 3. 3  Call  and  Return  Constructs 

Procedure  and  function  calls  in  J73  are  syntactically  similar  to  th«ir 
Ada  equivalents.  Parameter  passin*  mechanisms  are  semantically 
different*  J73  specifies  the  way  an  arsument  will  be  passed  to  and 
used  by  a  subroutine,  while  Ada  specifies  only  the  effect  a  subroutine 
may  have  on  an  argument.  The  difference  between  these  two  approaches 
involves  the  copyins  of  actual  parameter  values. 

J73  semantics  for  value  bindins  and  result  bindins  require  that  a  copy 
of  the  parameter  is  used  by  the  subroutine.  Ada  provides  two  parameter 
modes,  IN  and  IN  OUT,  which  require  copies  of  scalar  and  access  type 
arguments,  but  not  of  composite  (record  or  array  type)  arguments.  To 
ensure  that  composite  arsuments  are  passed  by  copyins,  the  Translator 
must  senerate  explicit  assisnment  statements  to  copy  composite 
parameters  into  and  out  of  temporary  locations  whenever  value  or 
result  bindins  is  used  for  blocks  and  tables. 
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In  general.  J73  input  parameters  will  be  translated  to  Ada  IN 
parameters*  and  J73  output  parameters  will  be  translated  to  Ada  IN  OUT 
parameters.  For  example,  the  procedure  declarations 

PROC  swap  Oaa.bb)!  "aa  and  bb  are  inteser  output  ars's" 

PROC  update  (newvaluei  buffer)!  "newvalue  is  floating 

buffer  is  a  table" 

PROC  tablecopv  (BYVAL  tablel >5  "tablet  is  an  input  value  are" 
will  be  translated  to 

PROCEDURE  swap  (aa'bbtlN  OUT  inteser)!  — value  result  binding 

PROCEDURE  update  <newvaluei  IN  F_tvpel  buffers  IN  OUT 
buf fer-type ) 5 

— value  binding  for  newvalue.  reference  binding  for  buffer 

PROCEDURE  tablecopv  (tableU  IN  tablel_tYPe ) ? 

— value  binding 


tablel.temp: = tablel S 

— ensures  that  a  copy  of  the  argument  is  used 


— references  to  tablel-temp  rather  than  tablel 

Explicit  copying  of  value  or  result  bound  composite  parameters,  as  in 
the  third  example*  maY  be  suppressed  bY  the  user  if  desired.  Arguments 
of  functions  will  be  translated  the  same  wav  as  procedure  arguments. 
Reference  binding,  which  is  used  in  J73  bY  default  for  tables  and 
blocks.  will  be  translated  to  IN  or  IN  OUT  parameter  binding  in  the 
hope  that  the  Ada  implementation  to  be  used  will  use  a  reference 
mechanism  for  such  parameters.  If  the  implementation  uses  a  coPYins 
mechanism.  then  the  subroutine  maY  have  an  undesired  effect  if  its 
context  is  changed  during  a  run-time  interrupt.  However,  it  would 
appear  unlikelY  that  an  implementation  would  ever  use  a  coPYins 
mechanism  for  composite  parameters.  since  reference  mechanisms  are 
generally  much  more  efficient. 
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Subroutine  name  parameters  will  be  translated  to  enumeration  objects. 
For  example,  the  procedure 

DEF  PROC  p!  ( tobecal 1 ed ) . 


PROC  to  he  called! 


in  which  the  formal  Parameter  “tobecal 1 ed"  may  assume  the  actual 
values  "  p5"  »  "p6".  or  "p7, '*  will  become  the  package 

WITH  p5_packase.  p&_peckage,  P7_package! 

PACKAGE  pl_packa*e  IS 

TYPE  tobecal led^tvpe  IS  (p5.  p&.  p7)i 
PROCEDURE  pi  (tobecal led*  IN  tobecal 1 ed_tvpe > s 


Using  this  translation,  a  call  to  the  formal  parameter  is  translated 
to  a  case  statements 

tobecal led!  “call  to  the  procedure  associated  with 
the  formal  parameter" 


becomes 

CASE  tobecal led  IS  —  which  proc  to  call? 

WHEN  p5  =>  p5!  — call  p5 
WHEN  p6  *>  p6!  — cal  1  p6 
WHEN  p7  =>  p7!  — call  p7 
END  CASE! 

in  which  the  procedure  names  *>5"  "p6"  and  "p7"  are  ov*  loaded  bv 
enumeration  literals  with  identically  spelled  names.  -bus.  the 
construct 

WHEN  p5  *>  p5! 

means.  "when  the  value  of  the  Parameter  "tobecal led"  is  the 
enumeration  literal  "p5".  call  the  procedure  named  "p5  (declared  in 
p5_pacakge ) . "  The  overloading  of  the  procedure  names  will  be 
unambiguously  resolved  bv  the  Ada  compiler. 
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ABORT  phrases  and  ABORT  statements  are  similar  to  Ada  exception 
handlers  and  RAISE  statements  in  that  theY  result  in  termination  of  a 
subroutine  without  bindine  the  values  of  output  parameters.  However, 
there  is  a  crucial  difference  between  ABORT'S  and  RAISE's?  Raisins  an 

exception  causes  control  to  be  transferred  to  a  special  section  of 

code  (an  exception  handler)  at  the  end  of  a  block  or  procedure  body* 
and  may  not  transfer  control  (GOTO)  back  into  any  other  place  in  the 
block  or  procedure.  In  contrast  to  this  wel 1 -structured  method  of 
prematurely  terminating  a  procedure  in  Ada.  the  J73  ABORT  causes  a 
virtually  unrestricted  GOTO  (to  any  part  of  a  call  ins  procedure)  which 
cannot  be  effected  usins  an  exception  mechanism.  Therefore.  ABORT 
phrases  and  statements  will  not  be  processed  by  the  Translator.  The 
user  mav  restructure  the  cal  line  routine  so  that  it  can  use  an 
exception  mechanism?  usually.  this  will  not  be  difficult  to  do  by 
hand.  Similarly.  statement  name  parameters  and  GOTO  statements  with 

formal  statement  name  parameter  tarsets.  which  are  special  cases  of 

the  ABORT  mechanism,  will  not  be  automatically  translated. 

Procedure  calls  and  function  calls  will  be  translated  usins  positional 
syntax.  as  in  J73.  so  that  calls  will  be  unchansed  by  the  Translator. 
The  only  exception  is  that  calls  to  parameter  1  ess  functions,  such  as 

currenttime  =  SYstemclock?  "call  to  function  with  no  erg's" 
will  use  empty  parentheses. 

cur rent t ime?  =  svstemcl ock ( ) ? 

as  is  required  in  Ada.  Return  statements  in  procedures  will  be 
unchanged  by  the  Translator,  consistin*  simply  of  the  reserved  word 
RETURN.  Functions  will  use  the  followins  translation  technique? 

a.  assignments  to  the  function  name  will  be  translated  to 
assignments  to  a  dummy  variable. 

b.  "RETURN"  will  be  translated  to  "RETURN  dummy_variable". 

For  example,  the  function 

PROC  cuberoot  (? number)  A  10.21?  "number  is  type  A  13.18" 

BEGIN 


cuberoot  =  expression? 
RETURN: 

END 
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will  be  translated  to 

FUNCTION  cuberoot  (number*  IN  OUT  A13_8_type_)  RETURN 
A10_21_type  IS 

cuberoot_resul ts  A10_21_type? 

BEGIN 


cuberoot_resul t? “expression* 

RETURN  cuberoot_resu1 t * 

END  cuberoot* 

This  technique  will  be  used  to  translate  each  function-name  assignment 
and  each  return  statement  occurring  within  a  function.  Procedures  and 
functions  declared  as  INLINE  will  result  in  the  insertion  of  the 
pragma.  "INLINE  procedure_name" .  into  the  program  at  the  point  of 
declaration. 

The  two  remaining  types  of  J73  statements,  stop  statements  and  null 
statements.  are  translated  as  RAISE  system-stop?  and  NULL* 
respectively.  The  former  statement  will  raise  an  exception  called 
"system-stop"  which  is  user  supplied  (or  may  be  supplied  by  an 
implementation).  If  an  integer  formula  is  included,  such  as 

STOP  22? 

the  Translator  will  generate  an  assignment  to  the  variable 

SYstem_stop_val ue  before  raising  the  exception? 

5Y5tem_stop_val ue?  =22? 

RAISE  svstem_stop? 

The  semantics  of  the  value  associated  with  the  stop  statement  are 
implementation  dependent  in  both  languages.  Declarations  of  this 
exception  and  variable  will  be  included  in  J73_predef ined-packase. 
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3.2.4  Directives 

t 

J73  provides  22  directives.  Ten  of  these  directives  will  be 
translated;  the  others  have  no  Ada  equivalents. 

The  compool  directive  (! COMPOOL)  is  translated  as  described  in 
3.2. 1.1.  The  copy  directive  (!COPY)  will  be  translated  to  PRAGMA 
INCLUDE,  havine  the  identical  effect  of  incorporating  an  external  file 
into  the  program  text  at  the  textual  location  of  the  directive.  The 
skip  directive  (ISKIP).  along  with  its  delimiters  (! BEGIN  and  'END), 
will  cause  the  Translator  to  insert  comment  delimiters  <" — " >  before 
each  line  of  text  in  the  J73  module  between  the  begin  and  end 
directives.  The  translated  module  will  then  include  the  non-translated 
J73  code  as  comments,  along  with  a  message  informing  the  user  of  the 
presence  of  the  skip  directive. 

The  linkage  directive  <! LINKAGE)  will  be  translated  to  the  interface 
pragma.  "PRAGMA  INTERFACE  < 1 anguase.name .  subprogram_name ) " .  where 
1 anguage_name  is  provided  bv  a  TPF  entry  and  subprogram-name  is  the 
name  of  the  procedure  or  function  which  used  the  linkage  directive. 
The  listing  directives,  !LIST  and  INOLIST,  will  be  translated  to 
"PRAGMA  LIST  (ON)"  and  "PRAGMA  LIST  (OFF)";  the  elect  directive, 
IEJECT,  will  be  translated  to  the  form  feed  symbol  used  by  the 
Translator's  host  environment  (unless  the  Ada  implementation  to  be 
used  features  an  eject  pragma,  in  which  case  that  pragma  will  be 
used).  The  initialize  directive,  1  INITIALIZE,  has  no  Ada  equivalent, 
but  will  be  effected  by  generating  a  preset  of  zeroes  for  all  static 
data  declared  in  the  scope  of  the  directive.  That  is,  "!=*0"  or  ":=0.0" 
or  " (O. . 99*>0. 0) " ,  etc.,  will  be  inserted  into  the  declaration  of  each 
static  object. 

Nine  of  the  J73  directives  (! TRACE.  ! INTERFERENCE,  IREDUCIBLE,  I  BASE , 
'.DROP,  '.ISBASE,  ILEFTRIGHT ,  ! REARRANGE »  and  ! ORDER )  have  no  predefined 
Ada  equivalent.  However,  a  particular  Ada  environment  will  probably 
include  features  which  are  identical  (or  at  least  similar  to)  many  of 
these  directives.  The  Translator  will  use  any  such  features  which  are 
available  via  TPF  entries  for  each  directive.  In  the  absence'of  a  T.’F 
entry,  the  directive  will  not  be  translated. 

The  remaining  directives,  ILISTINV,  1LISTEXP,  and  ILISTBOTH,  will  be 
discarded  by  the  Translator;  define  substitutions  are  not  translated 
per  se  (see  3. 2. 2. 2. 4),  so  that  these  directives  are  not  meaningful. 
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3.2.5  Intrinsic  Functions 

Most  J73  intrinsic  functions  have  Ada  equivalents.  Translation  of 
these  intrinsics  is  summarized  as  follows: 


J73 


Ada 


LOC(tablel) 
BIT(maskl.5.3) 
BYTE ( name. 0, 1 ) 
ABS(cl imbrate) 
BITSIZE(tablel) 
BYTESI ZE ( name ) 
WORDSI ZE ( mask  1 ) 
LBOUND( table  1.2) 
UBOUND ( tab  1 e 1  ) 
NWDSEN ( tab 1 e 1 ) 
FIRST ( points ) 
LAST (col  or ) 


tabl  el  •'ADDRESS 
maskl (5. . 12) 
name<0. .0) 

ABS( c 1 imbrate ) 

tab  lel_tYPe  •'SIZE 

name_t YPe'S I ZE /BITS INBYTE 

maskl-tYpe'SIZE/BITSINWORD 

tabl e i_tYPe 'FIRST (2) 

tab lel_tYpe 'LAST 

tabl el_tYPe"SIZE/BITSINWORD 

points_tYPe  ■'FIRST 

col or_tYpe'LAST 


In  the  examples  above,  the  BIT  and  BYTE  functions  are  translated  to 
slice  notation  as  discussed  in  3.2.2.  ManY  of  the  intrinsic  functions 
involving  object  size  or  position  are  translated  to  predefined 
attributes  of  the  objects-'  tYPes. 


The  remaining  J73  intrinsics.  NEXT.  SHIFT,  and  SGN,  will  be  translated 
to  sYntactical 1 y  equivalent  calls  to  predefined  functions  (except  for 
NEXT ( status_tYPe_variabl e ) .  which  translates  directlY  to 

enumeration_tYPe'SUCC(variable) ) . 

The  function  NEXT  will  be  declared  in  J73_predef ined_packase  as 
GENERIC 

TYPE  enum  IS  <<>>? 

FUNCTION  next  ( names enum? number : integer )  RETURN  enum  IS 
BEGIN 

IF  <  number>0)  THEN 

FOR  i  IN  1.. number  LOOP 

name  :*  enum'SUCC( name ) ? 

END  LOOP; 

ELSE  —  number  is  =<0 
number  :  =»  -number. 

FOR  i  IN  1.. number  LOOP 

name  :=  enum-'PREDf  name )  ? 

END  LOOPS 
RETURN  name? 

END  next? 
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a  function  call  such  as 
T(color,  2)  "second  successor  of  color" 
translated  to  a  generic  function  call 
T(co1or.2)  — same  as  J73  version 
udins  the  instantiation 

ICTION  next-color  IS  NEW  next < co 1 or_tvpe > ? 

translation  of  the  module.  A  similar  generic  must  be  supplied 
user  to  overload  NEXT  for  access  types  (in  an  implementation 
nt  manner)  if  the  NEXT  function  is  used  on  pointers.  The  SHIFT 
GN  functions  will  be  provided  by  the  Translator  in 

def ined-packase  as  generics  similar  to  NEXT,  so  that  expression 
as  SHIFTR(xx.S)  and  SGN(aa)  can  be  translated  using 
iations  such  as 

ICTION  shif tr_xx  IS  NEW  shiftr  <xx_type>» 


CTION  sgn_aa  IS  NEW  sen  (aa.type) I 


Miscellaneous  Functions 

arasraph  includes  a  discussion  of  several  issues  which  have  not 
xplicitly  covered  by  previous  paragraphs,  including  translation 
es  and  comments.  output  listing  format  of  the  translated  Ada 
and  translation  warning  messages. 


Names 


nhich  are  not  Ada  reserved  words  and  which  do  not  contain  the 
characters  or  will  be  unchanged  by  the  Translator.  The 

»r  M/'"  will  have  a  default  translation  of  "_"l  .  appearing 

first  character  of  a  name,  will  be  translated  to  "S_"»  a 
J  in  a  name  will  have  a  default  translation  of  Names 


ire  identical 
ision  "-user". 
Some  examples 


to  Ada  reserved  words  will  be  changed  to  include 
Labels  will  be  delimited  by  «...».  as  required 
of  name  translative  are  given  below> 
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J73  name 


Ada  name 


ai r speed 
dot-' product 
♦status 
mainicYC 1 e 
1  OOP 

statement label 


airspeed 
dot_rroduct 
S_status 
main_S_cYcle 
l oop-user 

«s  tat  ement  label  » 


Names  of  status  constants  uiill  be  translated  bY  removing  the  "v"  and 
the  parentheses*  so  that  "v(red)"  becomes  simplY  "red".  The  status 
constant  name  will  also  be  subject  to  the  rules  described  above  for 
special  characters  and  reserved  words*  and  will  be  qualified  with  a 
type  name  if  necessary,  as  discussed  in  3. 2. 2. 2.1. 


Each  of  the  rules  for  name  translation  (except  label  bracketing)  may 
be  overridden  bv  the  user,  if  desired.  This  is  accomplished  with  TPF 
entries  for  each  rule.  For  example*  the  user  mav  wish  to  translate  the 
"♦"  to  reserved  words  such  as  "loop"  to  "user_l oop" .  or  a 
status  constant  to  "v_red".  The  user  mav  prefer  "procl_packase"  to 
"procl_pack"  or  "tablel_record"  to  "tab! el_tYPe" .  These  preferences 
can  be  indicated  with  TPF  entries. 

The  Translator  is  responsible  for  detecting  name  conflicts  for  all 
names,  whether  user  generated  or  Translator-generated.  For  example,  if 
the  module  being  translated  contains  the  names  "range"  and 
"range 'user",  a  conflict  will  occurs  both  names  will  be  translated  to 
" range_user " .  The  Translator  must  inform  the  user  of  the  need  to 
change  either  one  of  the  names''  spelling  or  to  modifY  the  TPF  entrY 
for  one  of  the  two  cases  (translation  of  or  translation  of  Ada 
reserved  words). 


J73  implementations  normal 1y  permit  lower  case  letters  to  be  used  (the 
basic  character  set  is  upper  case).  Ada  also  uses  upper  case  as  its 
basic  character  set*  and  will  presumably  allow  lower  case  in  most 
implementations.  In  both  languages,  corresponding  upper  and  lower  case 
characters  are  considered  equivalent  (except  in  character  literal--, 
where  theY  are  distinct).  The  Translator  will  use  both  cases,  as  in 
the  examples  of  code  given  throughout  this  document,  unless  the  user 
wishes  otherwise.  A  TPF  entry  is  provided  for  this  purpose. 
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3. 2. 6. 2  Comments 

Although  comment*  have  no  semantic  effect  on  ft  prosram.  the  Translator 
uiill  attempt  to  preserve  all  comments  appearins  in  the  module  beins 
translated.  In  most  cases,  a  sinsle  J73  statement  with  a  comment  will 
translate  to  a  sinsle  Ada  statement  with  a  comment.  Source  lines 
consistins  of  nothins  but  comments  are  also  easily  handled: 

"This  is  a  comment 
that  uses  three  lines 
of  the  prosram" 

becomes 

— this  is  a  comment 
— that  uses  three  lines 
— of  the  prosram 

However.  comments  mav  be  embedded  within  a  statement  or  declaration, 
such  as 

IF  <aa<18.5)  "below  threshold"  AND  (bb>0)t 

Since  Ada  comments  always  extend  to  the  end  of  the  line,  an  embedded 
comment  will  either  be  moved  to  the  end  of  the  line 

IF  (ea<16. 5)  AND  <bb>0>!  —below  threshold 

or  will  be  left  in  place  while  the  remainder  of  the  statement  is  moved 
to  the  next  line: 

IF  (aa<18.5)  — below  threshold 

AND  ( bb>0) 5 

Selection  of  which  technique  is  used  is  left  as  a  user  option.  Another 
problem  occurs  when  a  sinsle  J73  statement  or  declaration  is 
translated  to  more  than  one  Ada  statement  or  declaration.  An  exam*  le 
siven  in  3. 2. 3. 2.  for  example,  maps  a  for  statement  into  two 
assisnment  statements  and  a  while  statement.  In  this  case,  the  comment 
will  be  placed  with  the  "key"  statement  of  the  Ada  translation: 

FOR  aa:bb  BY  cc  WHILE  dd>33»  "loop  throush  all  entries" 

will  be  translated  to 

aat«bb: 

WHILE  dd>ee  — loop  throush  all  entries 
LOOP 


aa:*ae+bbf 
END  LOOP! 
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The  Translator  will  also  create  comments  for  Ada  code  which  is 
Translator-generated.  For  example. 

TABLE  employees  (99)?  "personnel  records" 

BEGIN 


END 

will  result  in 

TYPE  empl oyees-type  IS 

RECORD  — describes  bodY  of  table  "employees" 


END  RECORD? 

employees?  ARRAY  (0..99)  OF  empl oYee_tYpe?  — personnel  records 

The  Translator  will  also  generate  comments  to  inform  the  user  of  the 
purpose  of  a  with  clause? 

WITH  compl?  — includes  items  aa.bb 

— and  tables  tabl.  tab2 

The  ur  *r  may  optionally  suppress  either  original  comments  or 
Translatoi — generated  comments. 


3. 2. 6. 3  Prettypr inting 

The  Ada  modules  output  by  the  Translator  will  be  printed  in  a  format 
which  corresponds  to  commonly  accepted  style  for  high  order  language 
programming.  Statements  within  logical  blocks  such  as  procedures. 
Ioops.  and  records  will  be  indented  one  tab  stop  (three  spaces) 
relative  to  the  enclosing  block.  Single  spaces  will  be  insert- d 
between  names.  operators.  and  reserved  words.  The  user  may  select 
either  upper  or  lower  case  letters  to  be  used  for  either  reserved 
words  or  names.  In  general.  the  code  will  be  formatted  like  the 
examples  given  throughout  this  Functional  Description. 

Warning  messages  will  be  inserted  into  the  output  text  as  necessary. 
The  messages  will  correspond  to  three  levels  of  severity.  Level  1 
warnings  inform  the  user  that  the  Translator  has  made  some  assumption 
(presumably  a  valid  assumption)  about  the  programming  environment.  For 
example,  when  translating  an  assignment  to  a  floating  point  type 
variable  which  was  declared  with  a  rounding  option,  the  message 

— **Llwarning?  assumes  presence  of  a  rounding  procedure** 
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will  b«  inserted  as  the  line  following  the  call  to  th«  rounding 
procedure.  Level  1  warnings  «r«  informational  and  may  b«  suppressed  bv 
the  user  if  desired. 

A  translation  which  introduces  a  possible  syntactic  or  semantic  error 
will  be  accompanied  by  a  Level  2  warning  message.  Examples: 

— **L2warnin«t  record  component  overlap  is  illegal** 

— **L2warnin*t  tarset  of  soto  is  inside  a  compound  statement** 

Untranslated  constructs  will  be  flagged  by  Level  3  warning  messages, 
such  as 

— **L3warnin»:  define  declaration  not  translated** 

— **L3warning:  order  directive  not  translated** 

Warning  messages  are  printed  as  Ada  comments  so  that  the  module  may  be 
compiled,  if  desired,  without  modification. 
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3.3  Inputs-Outputs 

This  paragraph  describes  the  input  and  output  requirements  of  the 
Translator. 


3.3.1  Input  Data 

Three  kinds  of  data  are  required  as  input  to  the  Translators  user 
commands.  J73  source,  and  translation  parameters. 


3.3. 1.1  User  Command  Input 

Users  of  the  Translator  must  provide  whatever  host-dependent  commands 
are  required  to  invoke  the  Translator  and  specify  input  and  output 
data  file  names. 

3.3. 1.2  J73  Source  Input 

The  J73  source  to  be  input  for  a  sinele  run  of  the  Translator  may  be 
any  portion  of  the  prosram  that  is  separately  compilable  by  a  J73 
compiler,  raneine  from  a  sinele  comrool .  procedure,  or  function  to  the 
entire  proeram.  All  J73  code  must  be  syntactically  correct,  which 
implies  that  it  has  been  previously  checked  by  either  a  compiler  or  a 
code  auditor.  Previous  compilation  or  auditine  of  the  J73  source  code 
is  not  manditory?  however.  because  the  Translator  will  not  perform 
syntax  checkins,  reliable  translation  will  result  only  from  input  that 
is  absolutely  free  of  syntax  errors.  Input  which  is  syntatically 
correct  but  erroneous  will,  in  eeneral .  have  unpredictable  results. 
Some  specific  instances  of  erroneous  prosram  translation  have  been 
discussed  in  previous  sections. 


3.3. 1.3  Translation  Parameter  File 

The  Translation  Parameter  File  (TPF)  will  be  used  by  the  Translator  .:o 
9uide  the  translation  of  J73  constructs  whose  mappine  to  Ada  is  either 
arbitrary  or  indefinite.  Examples  of  such  cases' are  variable  names 
containing  the  "V  or  characters,  variable  and  constant  names 
which  may  be  optionally  qualified  with  a  packase  or  type  name, 
optional  insertion  of  constraint  specifications  and  exception 
handlers,  and  selection  of  subroutine  areument-passine  modes.  The  TPF 
will  be  user  accessible  and  may  optionally  be  included  as  part  of  the 
Translator's  output  listine  (alone  with  the  Ada  proeram  itself). 
Certain  TPF  entries  may  be  overridden  by  user  command  inputs  so  that  a 
sinele  module  can  be  translated  in  a  special  manner  without  modifyine 
the  TPF. 
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3.3.2  Output  Produced 

The  Translator  will  produce  three  kinds  of  output*  translated  Ada 
modules*  generated  Ada  modules*  and  a  program  dictionary. 


3.3.2. 1  Translated  Ada  Nodule  Output 

The  major  output  of  the  Translator  will  be  a  listing  of  the  Ada  module 
produced  bv  a  run  of  the  Translator.  This  listing  will  be 
appropriately  formatted  ( “prettypr inted" )  to  conform  to  standard 
programming  practices*  including  indentation  to  exhibit  nesting* 
alignment  of  "begins"  and  "ends"*  and  form  feeds  for  modular  units 
<i.e.*  a  new  procedure  gets  a  new  page).  Comments  from  the  input  J73 
program  will  be  included  in  the  Ada  listing  if  reguested  by  the  user. 
Warning  messages  will  clearly  delimit  any  missing  Ada  cod* 
corresponding  to  untranslated  J73.  The  listing  may  be  output  to  either 
a  hard  copy  device  (printer)  for  human  inspection  or  to  a  file  (disk 
or  tape)  for  storage. 


3. 3. 2. 2  Generated  Ada  Module  Output 

Predefined  types  and  intrinsic  functions  in  J73  which  have  no  exact 
Ada  eguivalent  will  reguire  the  generation  of  special  modules.  These 
modules  will  be  Ada  packages  which  specify  predefined  types  unigue  to 
J73.  as  well  as  packages  which  either  implement  or  at  least  specify 
J73  intrinsic  functions.  In  the  latter  case*  intrinsics  whose 
implementation  is  target  dependent  rather  than  language  dependent  will 
be  represented  by  a  package  specification  with  a  body  stub.  This  will 
permit  the  user  to  implement  the  function  at  a  later  date  while 
ensuring  syntactically  correct  references  to  the  function  immediately. 
The  use  of  the  "generated  packages"  will  render  the  translated  Ada 
program  readable*  since  the  resulting  Ada  syntax  will  be  identical  to 
the  original  J73  syntax  for  'edef ined/intr insic  constructs.  In 
addition  to  clarity*  efficient.  1  flexibility  will  be  maintained! 
the  packages  generated  by  the  Tran*  -tor  may  be  changed  or  replaced  -y 
the  user  with  no  syntactic  impact  on  any  of  the  translated  modules. 


3. 3. 2. 3  Program  Dictionary  Output 

For  translation  purposes*  the  Translator  must  keep  an  internal 
dictionary  of  the  names  of  all  modules  and  externals  used  in  the 
program  being  translated.  A  listing  of  this  dictionary  may  be  output 
upon  reguest  of  the  user.  It  will  contain  the  name  of  each  library 
unit  in  the  Ada  translation*  as  well  as  external  names  listed 
according  to  which  library  unit  contains  either  a  definition  of  or  a 
reference  to  each  external . 
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3.4  Data  Characteristics 

The  storage  and  characteristics  of  the  data  elements  used  bY  the 
Translator  are  summarized  in  the  table  below. 


File  Description 

Mode 

Format 

Recommended  Device 

Type 

J73  Source 

input 

character 

sequential  or  direct  access 

Translation 
Parameter  File 

input 

character 

direct  access 

(TPF) 

List  of  J73 
Modules  bY 

File  Name 

input 

character 

direct  access 

Workspace 

internal 

binary 

direct  access 

Dictionary 

output 

character 

hard  copy 

Ada  Modules 

output 

character 

sequential,  direct 

access 

or  hard  copy 


The  sizes  of  these  elements  are  entirelY  dependent  on  the  size  of  the 
J73  source  prosram  beins  translated  (except  for  the  TPF.  which  will 
require  a  fixed  storase  size  of  about  IK  words). 


3.5  Failure  Continsencies 

No  failure  continsencies  are  required  for  this  sYstem. 
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SUMMARY  OF  PROBLEMATICAL  CONSTRUCTS 


Con*truct  Problem  Discussed  in  Paragraph 


Specified  tables  with  Illegal  in  Ada.  3. 2. 2. 2. 2 

overlapping  items 

Contiguous  storage  Contiguous  storage  is  3. 2. 2. 2. 4 

allocation  (Blocks)  not  guaranteed!  over- 

and  overlays  laved  storage  may  not 

be  provided  in  an  Ada 
impl ementation. 

Statement  name  No  similar  Ada  3. 2. 2. 2. 4 

declarations  construct. 

Define  declarations  Define's  are  expanded  3. 2. 2. 2. 4 

rather  than  translated. 

Expressions  with  side  Side  effects  are  not  3.2.3. 1 

effects  guaranteed. 

Label  parameters  and  No  similar  Ada  3. 2. 3. 3 

abort  statements  construct. 

Directives  Certain  directives  may  3.2.4 

not  be  provided  in  an 
Ada  implementation. 
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APPENDIX  2 

MIL-STD-1589B  CROSS  REFERENCE 

This  appendix  provides  a  cross-reference  for  J73  constructs  according 
to  the  sections  of  MIL-STD-1589B.  For  each  section  or  group  of  related 
sections  of  1589B*  the  subparagraph  of  this  Functional  Description 
which  is  applicable  is  given  in  the  right  column. 

1589B  Section  Eiiscussed  in  Paragraph 
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Appendix  2  -  MIL-STD-1589B  Cross  Reference 

1589B  Section 

-  Continued 

Discussed  in  Paraera 

4.0 

Statements 

3.2.3 

4. 1 

Assignment  Statements 

3.2.3. 1 

4.2 

Loop  Statements 

3. 2.3. 2 

4.3 

If  Statements 

3. 2. 3. 2 

4.4 

Case  Statements 

3. 2. 3. 2 

4.5 

Procedure  Cal  1  Statements 

3. 2. 3. 2 

4.6 

Return  Statements 

3. 2. 3. 3 

4.7 

Goto  Statements 

3. 2. 3. 2 

4.8 

Exit  Statements 

3. 2. 3. 2 

4.9 

Stop  Statements 

3. 2. 3. 2 

4.  10 

Abort  Statements 

3.2.3. 1 

5.0 

Formulas 

3.2.3.  1 

6.0 

Data  References 

3.2.1*  3.2.2*  3.2. 

6.  1 

Variables 

3. 2. 2. 2 

6.2 

Named  Constants 

3. 2. 2. 2.  1 

6.3 

Function  Cal  1  s 

3. 2. 3. 3 

6.3. 1-11 

Intrinsic  Functions 

3.2.5 

7.0 

Typo  Matchine  and  Conversions 

3.2.2. 1*  3. 2. 3.1 

8.  1 

Characters 

3.2.6. 1 

8.2 

Symbols 

3.2.6. 1 

8.3 

Literal s 

■3m  jHm2m  It  \3  m  2  m  2  m  j£  m  1 

8.4 

Comments 

3.2.6. 2 

8.5 

Blanks 

3*  2*  3 

9.0 

Directives 

3.2.4 
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ION  1.  GENERAL 

Purpose  of  tho  SYStem/SubsYstem  Specif ication 

SYstem/SubsYstem  Specif ication  for  tho  JOVIAL  <J73)  to  Ada 
islator  Invest ioat ion  (F30602-81-C-0127 >  is  written  to  fulfill 
followin*  objectives! 

a.  To  provide  definition  of  a  proposed  svstem  to 
translate  JOVIAL  (J73)  programs  to  Ada  prosrams. 

b.  To  communicate  details  of  the  on-soins  analysis 
between  potential  users  and  potential  development 
personnel . 


Project  References 

*rietarv  Software  SYstems  is  under  contract  to  the  Rome  Air 
Hopment  Center  to  investigate  the  automatic  translation  of 
iAL  (J73)  to  Ada.  The  SYstem  proposed  in  this  document  is 
mded  to  provide  production  aualitY  translation  of  JOVIAL 
>)  programs  to  Ada  in  accordance  with  the  Functional 
:ription  (10  JanuarY  1982)  and  the  Statement  of  Work  (PR  No. 
■3289)  for  the  project.  In  addition  to  these  documents, 
•rences  listed  in  Section  1.2  of  the  Functional  Description 
also  pertinent  to  the  project  and  will  be  cited  within  this 
iment. 


Terms  and  Abbreviations 

following  terms  and  abbreviations  will  be  used  throughout 
SYstem/SubsYstem  Specification! 

IA  Descriptive  Intermediate  Attributed  Notation 

for  Ada. 

neous  A  hieh  order  lansuase  proeram  which  contains 
one  or  more  violations  of  lansuase  semantics 
which  are  not  detected  bY  a  compiler. 
Erroneous  prosrams  have  unpredictable  run-time 
resul ts. 

rnal  A  rrosram  element  that  is  referenced  bY 

modules  which  are  compiled  separateW  from  the 
module  in  which  the  element  is  declared. 

The  prosrammins  lansuase  JOVIAL  (J73)  as 
specified  bY  MIL-STD-1589B. 
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Modul a 

Pars*  Tra* 

Proaram 

TPF 

Translator 


A  portion  of  a  J73  or  Ada  proaram  which  is 
loaicallY  distinct  from  tha  rast  of  its 
proaram  and  which  mav  ba  compilad  or 
translatad  saparataly. 

A  data  structur*  which  raprasants  tha  abstract 
syntax  of  a  hiah  ordar  lanauaaa  proaram  or 
modula. 

All  of  tha  modulas  of  a  J73  or  Ada  proaram*  as 
opposad  to  an  individual  compilation  unit. 


Translation  Paramatar  Fila  -  a  usar  accassibla 
fila  which  spacifias  which  translation  options 
will  ba  usad  for  a  run  of  tha  Translator. 

Tha  proposad  JOVIAL  <J73)  to  Ada  translator. 
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SECTION  2.  SUMMARY  OF  REQUIREMENTS 
2.1  Svstem/Subsystem  Description 

The  Translator  consists  of  a  computer  program  and  related  data 
needed  to  automatical 1y  translate  a  J73  program  to  an  equivalent 
Ada  program.  The  primary  inputs  to  the  Translator  are  J73  source 
modules  and  the  Translation  Parameter  File  (TPF).  The  Translator- 
produces  two  kinds  of  output  listings:  Ada  source  modules  (with 
diagnostics)  and  a  program  dictionary. 

The  purpose  of  the  Translator  is  to  provide  a  high  degree  of 
automation  to  the  process  of  converting  a  correct  J73  program  to 
an  equivalent  Ada  program.  The  J73  program  must  be  correct  in  the 
sense  that  it  contains  no  syntactic  or  semantic  errors  (i.e.»  it 
is  a  "debugged"  program).  Figure  2-1  illustrates  the  use  of  the 
Translator  in  the  software  conversion  process!  Figure  2-2  shows 
the  major  functional  components  of  the  Translator  itself. 
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BEGIN 

I 

l 

V 


.  J73 

.  SOURCE  . 
. MODULES. 


!  J73  SOURCE  ! 
!  CORRECTIONS  ! 


Translation  errors 


.  ADA 

.  SOURCE  .Translation  Errors 
.MODULES. - 


v 


!  Ada  Source  ! 

!  Corrections  !< - 


v 


>  9  !  Ada  Compiler  ! 

I  7 

•  v 


!  Test/Inte*rate  ! 


v 

END 


Fi»ure  2-l»  Software  Conversion  Cvcle 
with  Automatic  J73-to-Ada  Translation 
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!  EXEC  ! 


ANALYZE  ! 


!  SPEC  ! 


!  BODY  ! 


!  GEN  ! 


EXEC 

INIT 

TRAN 

ANALYZE 

SPEC 

BODY 

GEN 

LIST 


MAIN  EXECUTIVE 

GLOBAL  ANALYSIS  INITIALIZATION 
EXECUTIVE  FOR  MODULE  TRANSLATION 
MODULE  ANALYZER 

J73-TO-IL  FOR  PACKAGE  SPECIFICATION 
J73-T0-IL  FOR  PACKAGE  BODY 
GENERATE  ADA  FROM  IL 
OUTPUT  LISTINGS 


Fi*ura  2-2 *  Translator-  Structural  Components 
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2.2  SYstem/Subsvstem  Functions 

The  functions  of  the  Translator  are  summarized  in  this  paragraph. 
A  complete  description  of  these  functions,  including  details, 
examples,  and  exceptions,  appears  in  the  Functional  Description. 

In  translating  a  J73  program  to  Ada.  the  Translator  will  preserve 
the  modular  structure  of  the  program.  This  is  accomplished  bY 
translating  compools  and  procedures  to  packages.  The  J73 
constructs  which  reference  separately  compiled  modules,  the  REF 
and  the  compool  directive,  are  translated  to  Ada  WITH  clauses.  A 
J73  procedure  "PI"  containing  compool  directives.  REF 
declarations.  DEF  declarations.  and  local  declarations  will 
become  an  Ada  package  with  the  general  form: 

WITH  ...  —  names  of  other  packages  containing 

...  —  compools  and  declarations  of  REF'ed  objects 

PACKAGE  Pl_packase  IS 

PROCEDURE  PI  »  —  specification  of  PI 

...  —  declarations  of  other  DEF'ed  objects 

END  Pl._package*  —  end  of  package  specification 

PACKAGE  BODY  PI .package  IS 

...  —  declarations  of  local  STATIC  objects 

PROCEDURE  PI  IS  —  body  of  PI 

BEGIN 

...  —  remaining  local  declarations 

...  —  rest  of  the  procedure  body 

END  PI  ?  —  end  of  PI  body 

END  Pl.packase?  —  end  of  package  body 

This  translation  technique  is  valid  for  all  compools  and 
procedures  except  compools  containing  REF  declarations  and 
procedures  containing  partial  compool  inputs.  The  translations 
performed  in  these  cases  are  discussed  in  the  Functional 
De  script  ion. 

The  predefined  types  of  J73  (signed  and  unsigned  integer,  fixed 
and  floating  point,  character,  and  bit  types)  will  be  defined  in 
a  Translator-generated  package  called  " J73_predef ined.packase.  " 
Declarations  which  use  these  types  will  be  translated  to  Ada 
declarations  which  use  similar  type  names  (such  as  A14_l_type  for 
A  14.1)  and  preserve  all  the  attributes  and  type  matching 
properties  defined  by  J73  semantics.  Bit  and  character  types  are 
implemented  as  arrays.  so  that  the  "slice"  and  "aggregate" 
notations  are  used  to  denote  objects  of  bit  or  character  type. 
Status  types  translate  straightforwardly  to  enumeration  types. 
Serial  tables  are  translated  to  arrays  of  records,  where  each 
record  is  an  entry  of  the  table!  parallel  tables  become 
individual  records,  in  which  each  record  component  is  an  array. 
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Specified  representation  attributes  of  status  types  and  table 
types  utill  be  achieved  using  Ada's  representation  specification 
constructs.  Pointer  types  are  translated  to  access  types!  block 
types  (Dill  become  record  types.  Declarations  which  are  not 
perfectly  translated  include  specified  tables  with  overlapping 
item  positions.  statement  name  declarations,  and  overlay 
declarations.  Define  calls  are  expanded  inline,  so  that  define 
declarations  are  not  translated  per  se. 

Executable  constructs  are  similar  in  J73  and  Ada.  Arithmetic  and 
logical  operations  in  the  two  languages  have  matching  operators 
and  precedences.  so  that  translations  will  not  require  extra 
parentheses  or  special  functions.  Type  conversions  between 
closely  related  types  are  also  straightforward.  but  conversions 
between  unrelated  types  and  conversions  involvin*  pointers, 
status  objects.  and  the  REP  function  are  translated  to  calls  to 
the  generic  function.  UNCHECKED-CONVERSION.  Assignment  statements 
translate  directly.  with  assignments  to  several  variables  in  a 
single  statement  translated  to  several  separate  assignments.  Side 
effects  of  expression  evaluation  order  and  assignment  evaluation 
order  will  not  be  preserved  by  the  Translator.  Control  statements 
<FGR.  IF.  and  CASE)  translate  to  the  corresponding  Ada 
statements.  with  major  restructuring  required  on  certain  classes 
of  FOR  statements  and  minor  restructuring  of  some  CASE 
statements. 


Procedures  and  function  calls  are  translated  to  syntactically 
similar  Ada  calls.  with  input  parameters  passed  in  IN  mode  and 
output  parameters  passed  in  IN  OUT  mode.  Code  that  explicitly 
copies  value  or  result  bound  parameters  is  generated  by  the 
Translator  for  cases  in  which  Ada  does  not  guarantee  the 
necessary  value  or  result  binding  mechanisms.  Label  parameters, 
subroutine  name  parameters.  and  abort  statements  are  not 
translated;  they  must  be  hand  coded  using.  for  example,  an 
exception  mechanism. 

Ten  of  the  22  directives  provided  by  J73  have  simple  Aoa 
equivalents.  The  three  directives  related  to  define  expansions 
are  not  needed;  the  remaining  directives  (ITRACE.  ! INTERFERENCE. 
•REDUCIBLE.  'BASE,  !DROP,  ! ISBASE,  ! LEFTRIGHT ,  IREARRANGE,  and 
•ORDER)  will  be  translated  only  if  the  Ada  implementation  to  be 
used  provides  corresponding  constructs,  since  no  such  constructs 
are  predefined  in  the  language. 

Ada  provides  predefined  attributes  of  types  which  are  used  for 
translation  of  most  J73  intrinsic  function  calls.  The  BIT  and 
BYTE  functions  are  translated  to  slice  notation.  The  NEXT,  SHIFT, 
and  SON  intrinsics  will  be  translated  to  generic  functions 
declared  in  J73_predef i ned_packase . 
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The  Translator  mill  process  names  in  a  highly  flexible  manner. 
The  user  may  control  the  translation  of  names  containing  the 
and  characters.  as  well  as  the  names  of  Translator-generated 

objects-  using  TPF  entries.  The  Translator  mill  detect  any  naming 
conflicts  or  violations!  it  mill  also  preserve  the  original 
comments  and  create  comments  for  Translator-generated  code. 
Diagnostics  mill  be  embedded  in  the  output  listing  to  inform  the 
user  of  assumptions  or  inaccuracies  in  the  translation  of  a 
module.  The  output  listing  mill  conform  to  normal  standards  for 
structured  programming  mith  regard  to  format*  indentation,  etc. 


2.2.1  Accuracy  and  Validity 

The  translations  performed  by  the  Translator  mill  be  accurate  in 
the  sense  that  the  resulting  Ada  programs  mill  be  semantically 
equivalent  to  the  J73  programs  from  mhich  they  mere  derived  to 
the  largest  extent  possible.  Except  for  certain  untranslated 
constructs.  mhich  mill  be  clearly  flagged  in  the  output,  the  Ada 
produced  by  the  Translator  mill  be  a  valid  Ada  program  in  that 

a.  It  mill  contain  no  syntax  errors* 

b.  Any  missing  code  that  is  required  for  execution  of 
the  program  mill  be  clearly  identified* 

c.  It  mill  be  compilable  in  a  standard  Ada  environment 
mithout  modifications  (such  as  reorganizing 
statements  and  declarations  or  renaming  modules  or 
variables ) * 

d.  It  mill  conform  to  general  standards  for  readable, 
mell  structured  programming. 

In  general.  tmo  versions  of  a  program  cannot  be  guaranteed  to 
have  absolutely  identical  run-time  behavior  in  tmo  different 
environments.  even  if  the  versions  mere  generated  from  the  sam- 
source  code  (e.s..  a  J73  program  compiled  for  tmo  different 
targets).  Therefore,  the  Translator  cannot  be  required  to  produce 
a  "perfect"  translation  of  a  non-trivial  program.  Homever.  it 
mill  be  required  to  preserve  the  original  program  semantics 
mherever  possible,  at  the  expense  of  some  run-time  efficiency  if 
necessary,  and  to  inform  the  user  of  any  possible  deviations  from 
•J73  semantics  that  are  introduced  bv  the  translation. 
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2.2.2 


Timing 


Although  Portions  of  a  program  mav  r«suire  repeated  translation 
t.  resolve  various  translation  problems,  the  overall  translation 
Process  Bill  be  a  one-time  task.  Nigh  Performance  lith  rJIiiJt  tS 
throughput  is,  therefore,  not  given  a  high  Priority  The 
Translator  should  Process  J73  source  code  at  about  the  same’seeed 

mainf rame^host'  system! V  l°°  ‘°UrC*  Un*S 


2.2.3  Flexibility 


Flexibility  in  the  Translator 
'ranslation  Parameter  File,  which 


is  provided  bv  use  of  the 
is  discussed  in  Section  4.3.1. 
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SECTION  3.  ENVIRONMENT 
3.1  Equipment  Environment 

A  general  purpose,  medium  scale  mainframe  computer  will  be  needed 
to  support  the  Translator  and  its  associated  data.  The  host 
environment  must  include  enough  direct  access  memory  to  store  the 
Translator.  the  J73  program  being  translated,  and  all  related 
data.  such  as  svmool  tables,  intermediate  representations  of  the 
^modules  under  translation.  and  output  data.  A  host  environment 
which  is  capable  of  supporting  storage  and  compilation  of  a  given 
J73  program  will  be  adequate  for  support  of  the  translation  to 
Ada  of  that  program*  no  new  processors,  memories,  or  input/output 
devices  will  be  reguired. 


3.2  Support  Software  Environment 

The  Translator  will  operate  under  control  of  a  general  purpose 
operating  system.  Invocation  of  the  Translator,  specification  of 
input  and  output  files,  and  modification  of  J73  code  for 
re-translation  (as  shown  in  Figure  2-1)  will  require  the  Jot- 
control  ,  file  management,  and  text  editing  capabilities  which  are 
provided  bv  a  typical  operating  system  on  a  medium  scale 
computer.  No  new  support  software  should  be  necessary.  The 
Translator  could  be  intesrat^ d  into  an  Ada  Prosraromi ng  Support 
Environment  (APSE),  but  this  is  not  an  inherent  requirement.  For 
example,  if  the  Translator  were  implemented  in  Ada,  an  APSE  would 
be  necessary  for  maintenance  and  run-time  support?  however,  if  it 
were  implemented  in  J73*  a  J73  compiler  (and  linker)  would  be 
needed  —  an  APSE  would  be  unnecessary. 
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SECTION  4.  DESIGN  DETAILS 

4.1  General  Operating  Procedure* 

To  translate  a  J73  program  to  Ada*  the  user  must  successfully 
complete  two  sets  of  tasks.  First*  the  translation  process  must 
be  initialized!  second*  individual  modules  can  be  translated  to 
Ada  modules. 


4.1.1  Initializing  the  Translator 

The  translation  process  is  begun  by  invoking  the  Translator  in 
INIT  mode.  The  inputs  required  in  this  mode  are  the  TPF,  the 
program  module  list*  and  all  of  the  source  files  of  the  J73 
program  to  be  translated  (see  Section  4.3.1  for  detailed 
discussion  of  these  inputs).  When  the  Translator  runs  in  INIT 
mode*  it  will  use  the  TPF  and  the  module  list  to  perform  a  global 
analysis  of  the  J73  program.  The  initialization  process  must  be 
repeated  if  a  fatal  error  is  detected  during  the  global  analysis* 
or  if  the  user  changes  either  the  modular  structure  of  the 
program  (requiring  a  corresponding  change  in  the  module  list)  or 
the  TPF.  After  obtaining  an  INIT  run  with  no  fatal  errors, 
translation  of  individual  modules  may  begin. 


4.1.2  Translating  Nodules  to  Ada 

One  module  may  be  translated  to  Ada  per  run  of  the  Translator. 
When  invoking  the  Translator  in  TRAN  mode*  the  inputs  required 
are  the  J73  module  to  be  translated  and  the  TPF.  The  global 
analysis  performed  during  INIT  will  be  updated  if  necessary*  and 
an  Ada  translation  will  be  output  (with  diagnostics).  The  user 
may  re-translate  a  module  for  any  of  the  following  reasons: 

a.  The  module  was  modified  to  correct  a  translation 
error* 

b.  The  module  was  modified  for  algorithmic  reasons! 

c.  The  module  references  another  module  which  was  re¬ 
translated  since  the  current  module  was  last 
transl atedl 

d.  The  user  requires  a  repeat  of  an  earlier 

translation  to  obtain  additional  output  listings. 
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The  Translator  will  issue  diagnostics  which  advise  the  user  of 
needed  re-translations  tor  cases  a.  and  c.  In  some  cases* 
modification  of  an  individual  module  ma\'  require  reinitialization 
(for  example*  when  adding  or  deleting  compool  directives  from  a 
modul e ) . 


4.2  System  Logical  Flow 

The  Translator  system's  logical  flow  is  described  by  the  Software 
Conversion  Cycle  (Figure  2-1)  and  by  the  chart  of  Figure  4-1. 
Further  details  are  presented  in  Section  4.4. 
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4.3  System  Data 

The  following  paragraphs  describe  the  inputs.  outputs,  and 
internal  data  used  by  the  Translator. 


4. 3. 1  Inputs 


Four  types  of  inputs  are  required  bv  the 
input,  J73  source  modules,  a  J73  module  list, 
parameters. 


Translators  command 
and  the  translation 


4.3. 1.1  Command  Input 

A  user  of  the  Translator  must  supply  command  input  to  specify  the 
fol 1  owing  items: 

a.  Mode  (INIT  or  TRAN) 

b.  Options  (output  listing;  analyze/translate) 

c.  File  names  or  device  names  of  inputs  and  outputs. 

The  options  that  may  be  requested  include  dictionary  listings, 
listings  of  Ada  source  generated  bv  the  Translator  (see  4. 3. 2. 2), 
and  diagnostic  suppression.  Uhen  invoking  TRAN  mode,  the  user  may 
specify  analysis  only  (for  diagnostics),  translation  onlv  (for 
translating  a  module  which  has  not  been  modified  since  it  was 
last  analyzed),  or  both  (default).  The  user  must  inform  the 
Translator  (via  the  operating  system)  of  the  (host-dependent) 
file  or  device  names  needed  for  a  run  of  the  Translator, 
including  the  names  of  the  files/devices  to  be  used  for  input  and 
output  J73  and  Ada  modules,  the  TPF,  the  module  list,  and  the 
dictionary. 


4.3. 1.2  J73  Source  Input 


To  initialize  the  Translator,  the  user  must  provide  the  source 
code  of  the  entire  J73  program  to  be  translated.  To  translate  n 
individual  module,  the  user  must  provide  the  source  code  for  any 
portion  of  the  program  that  is  separately  compilable  by  a  J73 
compiler  (i.e.,  a  single  file  whose  first  line  is  START  and  whose 
last  line  is  TERM). 


All  J73  code  must  be  syntactically  correct,  which  implies  that  it 
has  been  previously  checked  by  either  a  compiler  or  a  code 
auditor.  Previous  compilation  or  auditing  of  the  J73  source  code 
is  not  mandatory;  however,  because  the  Translator  will  not 
process  syntactically  incorrect  input,  reliable  translation  will 
result  only  from  input  that  is  absolutely  free  of  syntax  errors. 
Input  which  is  syntactically  correct  but  erroneous  will,  in 
general,  have  unpredicable  results.  Some  specific  instances  of 
erroneous  program  translation  are  discussed  in  the  Functional 
Description. 
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3.1.3  Module  List  Input 

i  order  to  perform  the  global  analysis  of  the  J73  program  during 
IT  mode.  the  Translator  must  have  a  means  of  identifying  the 
urce  files  of  the  program  according  to  module  type  (compool, 
ogranti  procedure,  or  copy).  This  information  is  input  using  the 
dule  List.  The  Module  List  is  a  text  file  consisting  of  one 
cord  <i.e..  card  image)  for  each  J73  source  file  to  be 
anslated.  Each  record  has  the  the  format 

<filename>  <type> 

ere  the  filename  is  a  host-dependent  identifier  and  the  type  is 
ther  "compool "program",  or  "procedure",  if  the  file  contains 
paratel y  compilable  J73  source,  or  "copy",  if  it  contains  text 
ich  is  input  bY  one  or  more  modules  using  a  COPY  directive.  The 
dule  List  enables  the  Translator  to  perform  a  top-down  analysis 
the  program  without  requiring  the  user  to  submit  the 
idividual  modules  in  J73  "compilation  order". 


3.1.4  Translation  Parameter  Input 

e  Translation  Parameter  File  (TPF)  is  used  to  guide  the 
anslation  of  .J73  constructs  whose  mapping  to  Ada  is  either 
bitrarr  or  indefinite.  The  content  of  the  TPF  is  described  in 
pendix  1.  The  TPF  is  a  user-accessible  text  file;  it  mar  be 
dified  before  initialization  of  the  Translator  (see  4.1,1)  and 
y  be  listed  or  copied  anytime. 

tries  in  the  TPF  for  the  control  of  li'ving  formats  and  comment 
ocessins  mar  be  overridden  bY  user  command  inputs  for 
dividual  Translator  runs;  other  translation  parameters  must 
main  constant  throughout  the  translation  of  a  program. 


3.2  Outputs 

e  Translator  produces  three  types  of  outputs:  Ada  source  code 
anslated  from  J73,  Ada  source  code  generated  bY  the  Translator, 
d  a  program  dictionary.  Each  of  these  outputs  mar  either  be 
ored  in  a  file  or  sent  to  a  device  such  as  a  terminal  or 
inter. 
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4.3.2. 1  Translated  Ada  Module  Output 

The  major  output  of  the  Translator  will  be  a  listing  of  the  Ada 
module  produced  bv  a  run  of  the  Translator.  This  listing  will  be 
appropriate! v  formatted  < "prettYPr inted" )  to  conform  to  standard 
programming  practices.  including  indentation  to  exhibit  nesting, 
matching  of  "begins”  and  "ends",  and  form  feeds  for  modular  units 
(i.e..  a  new  procedure  sets  a  new  pase).  Comments  from  the  input 
J73  program  will  be  included  in  the  Ada  listing  if  requested  bY 
the  user.  Warning  messages  will  clearly  delimit  any  missing  Ada 
code  corresponding  to  untranslated  J73.  The  listing  may  be  output 
to  either  a  hard  copy  device  (printer)  for  human  inspection  or  to 
a  file  (disk  or  tape)  for  storage. 


4. 3. 2. 2  Generated  Ada  Module  Output 

A  number  of  J73  constructs,  including  predefined  types,  certain 
intrinsic  functions,  and  certain  type  converisons.  have  no  exact 
Ada  equivalent.  Each  such  construct  is  translated  to  a  type  or 
function  which  is  declared  in  a  special  Ada  package  called 
"J73_predef ined_package".  This  package  is  derived  by  the 
Translator  during  INIT  mode.  updated  as  necessary  during  TRAN 
mode.  and  output  as  Ada  source  code  upon  user  command.  The 
rationale  for  the  generation  of  J73_predef  ined_packa.ge  is 
discussed  in  section  3.2.2. 1  of  the  Functional  Description?  the 
specific  contents  of  the  package  are  described  in  sections  3.2.2. 
3.2.3. 1.  and  3.2.5  of  the  Functional  Description. 


4. 3. 2. 3  Program  Dictionary  Output 

For  translation  purposes.  the  Translator  must  keep  an  internal 
dictionary  of  the  names  of  all  modules  and  externals  used  in  the 
program  being  translated.  A  listing  of  this  dictionary  may  be 
output  upon  request  of  the  user.  It  will  contain  the  name  of  each 
library  unit  in  the  Ada  translation,  as  well  as  external  name> 
listed  according  to  which  library  unit  contains  either  a 
definition  of  or  a  reference  to  each  external. 


4.3.3  Data  Base 

This  section  defines  the  internal  data  base  elements  used  by  the 
Translator.  The  principle  structures  are  the  Module  Table  (one 
for  the  entire  J73  program)  and  the  symbol  table,  parse  tree,  and 
DIANA  tree  (one  each  for  every  J73  module). 
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4.3.3. 1  Module  Table 

The  program  module  table  (ModTab)  is  a  Global  data  base  which  is 
used  to  store  information  about  modules  and  externals.  ModTab  is 
initialized.  using  the  user-supplied  Module  List,  to  include  an 
entry  for  each  J73  source  module  that  identifies  each  module  as  a 
compool.  program.  procedure.  or  function.  As  each  module  »s 
analyzed  <see  4.4.3).  its  ModTab  entry  is  filled  in  with  the 
following  data! 

a.  Number  of  other  modules  referenced  (by  REF's.  copy 
directives,  and  compool  directives)! 

b.  For  each  module  REF'ed,  a  pointer  to  that  module's 
ModTab  entry. 

c.  For  each  compool  which  is  selectively  imported,  a 
pointer  to  a  list  of  selected  names! 

d.  A  pointer  to  the  module's  symbol  table! 

e.  A  pointer  to  the  module's  parse  tree. 

The  informatics  contained  in  ModTab  permits  the  Translator  to 
resolve  moo^le  dependencies  and  external  references,  to  manage 
the  creation  and  replacement  of  symbol  tables  and  parse  trees, 
and  to  generate  a  program  dictionary.  The  internal  structure  of 
ModTab  is  implementation  dependent. 


4. 3. 3. 2  J 73  Module  Representation 

Each  J73  module  is  internally  represented  by  a  symbol  table 
(SymTab)  and  a  parse  tree.  These  two  structures  contain  the 
syntactic  and  semantic  data  which  the  Translator  requires  for  the 
analysis  and  translation  of  individual  J73  modules.  The  parse 
tree  provides  a  basis  for  the  translation  to  DIANA  (see  4.4.5  a.»d 
4.4.6)  that  is  much  more  efficient  than  the  direct  processing  of 
card  image  source  text  would  be.  The  SymTab.  alone  with  ModTab. 
serves  as  the  primary  data  base  used  in  the  analysis  of  J73 
modules  (described  in  4.4.3)!  it  also  doubles  as  the 
identifier-attribute  portion  of  the  DIANA  tree,  as  described  in 
the  next  section. 
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4. 3. 3. 3  Intermediate  Language 

The  intermediate  form  of  the  Ada  module  to  be  output  by  the 
Translator  is  a  DIANA  syntax  tree.  The  DEF_ID  nodes  of  the  tree 
are  implemented  as  pointers  into  S'ymTab,  so  that  the  attributes 
of  each  variable  do  not  need  to  be  stored  redundantly  in  the 
tree.  Semantic  and  code  attributes  which  are  irrelevant  to  the 
translation  process  (such  as  sm_contraint  and  cd_al i9nment )  are 
omitted.  Two  structural  attributes  have  been  added: 
as_error_number .  which  contains  the  identifier  of  a  diagnostic* 
and  as_error_l ink.  whose  value  is  a  pointer  into  the  J73  parse 
tree.  These  attributes.  whose  values  are  set  to  zero  in  the 
absence  of  translation  errors,  permit  straightforward  generation 
of  diagnostics  bv  GEN  (see  4.4.7).  Aside  from  these 
modifications.  the  DIANA  tree  conforms  to  the  DIANA  Reference 
Manual  (reference  Cml). 


4. 3. 3. 4  Other  Data  Base  Elements 

The  Translator  executive  (4.4.1)  creates  a  parameter  table 
(F'armTab)  based  on  the  TPF.  Because  the  translation  parameters 
are  needed  frequently  throughout  the  translation  process.  ParmTab 
is  structured  in  a  manner  that  permits  very  efficient  lookup  of 
the  parameter  values. 

The  J73_predef i ned_packase  (4. 3. 3. 2)  is  internally  constructed  as 
a  DIANA  tree.  The  tree  is  expanded  by  SPEC  (4.4.5)  during  the 
translation  of  each  module,  and  is  converted  to  Ada  source  by  GEN 
(4.4.7)  upon  user  command. 

Other  data  includes  a  file  of  diagnostic  message  text,  a  table  of 
J73  and  Ada  reserved  words  and  symbols,  the  J73  parser  table,  and 
a  file  of  diagnostics  generated  during  INIT  mode. 


4.4  Program  Descriptions 

The  following  paragraphs  describe  the  major  functional  components 
of  the  Translator.  The  hi.hest  structural  level  is  depicted  in 
Figure  2-2*  the  next  highest  level  is  discussed  in  this  section. 
Lower  levels  of  the  program  structure  will  depend  on  the  details 
of  an  actual  implementation  of  the  Translator. 
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4.4.1  EXEC 

The  entry  point  of  the  Translator  is  called  EXEC.  EXEC  performs 
tuio  functions:  it  contains  all  of  the  routines  which  comprise  the 
interface  between  the  Translator  and  its  host  operating  system 
and  it  serves  as  the  main  executive  of  the  rest  of  the  prosram. 
If  the  Translator  is  implemented  using  overlays*  EXEC  will 
include  the  commands  necessary  to  accomplish  the  overlays. 

The  processing  performed  by  EXEC  is  shown  in  Figure  4-2.  The 
parameter  table  (ParmTab)  is  constructed  from  the  TPF?  other 
variables  are  initialized  based  on  user  command  inputs.  EXEC  then 
calls  either  INIT  or  TRAN.  based  on  the  mode  selected  by  the 
user,  and  then  calls  LIST  to  complete  the  Translator  run. 
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4.4.2  INIT 

INIT  is  the  main  routine  for  control  line  the  Translator  in  INIT 
mode.  The  primary  function  of  INIT  is  to  submit  individual  J73 
modules  to  ANALYZE  (see  4.4.3)  in  an  order  which  permits  an 
efficient  global  analysis  of  the  J73  program  to  be  performed. 

In  attempting  to  analyze  a  J73  module  whose  context  may  include 
compool  data,  two  approaches  are  possible.  The  first  approach  is 
to  use  a  compool  output  file  to  store  the  results  of  an  analysis 
of  the  compool.  The  compool  output  file  can  then  be  imported  into 
the  data  base  (i.e..  symbol  table)  of  the  module  which  references 
it.  before  the  module  itself  is  analyzed.  This  approach  is 
appropriate  for  compilation  of  J73  for  two  reasons! 

a.  J73  modules  may  be  coded  and  compiled  in  the  order 
in  which  they  must  be  analyzed  bv  the  compiler. 

b.  To  compile  £  module  which  imports  a  compool.  the 
compiler  needs  access  only  to  the  appropriate 
compool  output  files  (not  to  the  compool  source). 

Since  these  reasons  are  not  applicable  to  the  task  of  translating 
a  complete.  previously  written  J73  program  to  Ada.  a  different 
approach  has  been  devised  for  use  bv  the  Translator.  During  INIT 
mode.  the  Translator  builds  a  9lobal  data  base  by  analysing  each 
source  module  in  "compilation  order"! 

a.  First,  "stand-alone"  coikpooIs! 

b.  Then,  compool s  which  import  other  compool s' 

c.  Finally,  the  program,  procedure,  and  function 
modul es. 

This  approach  removes  the  need  for  compool  input/output 
processing.  All  the  source  files  are  available  to  the  Translator 
at  once  during  INIT  mode*  using  information  in  the  module  table 
(ModTab),  the  INIT  routine  derives  a  correct  order  of  analysis 
and  proceeds  to  call  ANALYZE  for  each  module,  building  toe 
required  global  data  base  without  the  help  of  either  compool 
output  files  or  of  a  user-controlled  ordering.  This  is  a  major 
advantage:  it  frees  the  user  of  the  Translator  from  the  task  of 

manually  deriving  an  acceptable  ordering  (a  difficult  task  for  a 
1000  module  program!)  and  also  eliminates  the  time  and  space  that 
would  have  been  consumed  bv  the  creation  and  use  of  compool 
output  files. 

Before  submitting  the  >J73  source  modules  to  ANALYZE  in  the 
fashion  described  above.  INIT  creates  ModTab  from  the 
uesr-suppl ied  Module  List.  INIT  will  terminate  the  analysis 
process  when  ANALYZE  detects  a  fatal  error  in  a  module.  A  diagram 
of  INIT  appears  in  Figure  4-3. 
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4.4.3  ANALYZE 

The  purpose  of  the  ANALYZE  routine  is  to  perform  an  analysis  of 
an  individual  J73  source  module  in  the  context  of  the  entire  J73 
program  being  translated.  To  do  this*  it  is  required  that  all 
modules  on  which  a  given  module  depends  have  been  previously 
analysed  (as  discussed  in  the  preceeding  section).  ANALYZE  may  be 
called  during  INIT  mode.  to  perform  the  initial  analysis  of  a 
module.  or  during  TRAN  mode,  to  update  the  analysis  for  a  new 
trans 1  at  ion. 

Processing  in  ANALYZE  occurs  in  two  parts,  as  shown  in  Figure 
4-4.  The  first  part  is  a  syntactic  analysis,  in  which  the  J73 
source  module  is  converted  to  a  SymTab  and  a  parse  tree.  The 
second  part  is  an  updating  of  the  internal  data  bases  related  to 
the  module  analysis. 

Syntactic  analysis  involves  three  routines!  a  tokenizer.  a 
parser,  and  an  error  detector.  The  tokenizer  performs  a 
table-driven  lexical  analysis  of  each  J73  symbol.  It  returns  a 
keyword  token  for  each  predefined  J73  symbol,  and  a  name  token 
(i.e.,  a  character  string)  for  each  user  defined  symbol.  The  name 
tokens  reflect  the  translated  spellings  of  the  user  defined 
symbols.  permitting  detection  of  name  conflicts  during  the 
analysis.  The  parser-  expands  the  symbol  table  and  parse  tree  to 
reflect  the  syntactic  content  of  the  module  using  a  conventional 
bottom-up  parse  algorithm.  The  parser  may  be  generated 
automatically  using  a  commercially  available  parser-generator,  as 
in  Cg3,  or  may  be  manually  coded.  In  either  case,  the  parser  will 
generate  simple  diagnostics  for  any  J73  syntax  errors.  no 
extraordinary  error  recovery  techniques  are  needed,  since  the  J73 
input  is  supposed  to  be  syntactically  correct.  However,  since  the 
J73  code  may  contain  untranslatable  constructs,  the  error 
detector  is  called  by  the  parser  to  detect  problematical  J73 
constructs  (see  Appendix  1  of  the  Functional  Description)  and 
name  conflicts.  making  an  entry  in  a  diagnostics  file  for  each 
error  detected.  The  syntactic  analysis  is  depicted  in  Figure  4-5. 


Upon  detection  of  an  irrecoverable  error,  such  as  a  missing  copy 
file,  missing  compool,  or  J73  syntax  error,  ANALYZE  will  delete 
the  erroneous  SvmTab  and  parse  tree  created  by  the  syntatic 
analysis.  If  no  fatal  errors  are  encountered,  ModTab  is  searched 
to  yield  the  names  of  all  modules  which  reference  the  current 
module.  The  names  of  these  modules  and  their  corresponding  source 
files  are  stored  in  a  table  for  use  by  LIST.  If  ANALYZE  was 
called  to  update  a  module's  analysis  (rather  than  initialize  it), 
the  final  action  taken  is  to  delete  the  module's  previously 


created  SvmTab  and  parse  tree. 


1 

i 

-J 
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4.4.4  TRAN 

TRAN  is  the  routine  which  controls  the  Translator  during  TRAN 
mode.  As  shown  in  Figure  4-6.  TRAN  is  a  simple  executive  whose 
function  is  to  call  other  routines  based  on  the  anal Yze/translate 
option  requested  by  the  user  (see  Section  4.3. 1.1). 

The  user  may  wish  to  have  a  module  analyzed,  to  detect  possible 
translation  errors  or  name  conflicts,  without  needing  an  actual 
Ada  source  output.  This  is  analogous  to  running  a  module  though  a 
compiler  with  a  "syntax  only"  option;  the  user  may  obtain 
"front-end"  diagnostics  without  paying  for  "back-end"  processing. 
In  this  case.  TRAN  will  call  ANALYZE  and  then  return  without  an. 
further  processing.  Conversely,  the  user  may  wish  to  translate  a 
module  which  has  not  been  modified  since  it  was  last  analyzed. 
This  situation  occurs  when 

a.  The  module  has  not  been  translated  or  modified 
since  Translator  initialization,  or 

b.  The  user  desires  additional  output  listings 
for  the  existing  version  of  a  module. 

In  this  case,  TRAN  bypasses  the  call  to  ANALYZE  and  calls  the 
routines  SPEC,  BODY,  and  GEN  to  perform  the  translation  based  on 
a  prior  analysis  of  the  module. 
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4.4.5  SPEC 

SPEC  is  the  first  of  two  routines  which  translate  the  J73  parse 
tree  created  bv  ANALYZE  into  a  DIANA  tree  which  represents  the 
Ada  translation  of  a  module.  The  output  of  SPEC  is  the  portion  of 
the  DIANA  tree  needed  to  represent  the  specification  (i.e.. 
visible  part)  of  the  package  into  which  the  J73  module  will  be 
translated.  The  DIANA  tree  is  completed  bv  BODY.  which  is 
discussed  in  the  next  section. 

The  translation  of  the  J73  parse  tree  to  DIANA  is  based  on  a 
top-down  traversal  of  the  parse  tree.  SPEC  ignores  the  portions 
of  the  parse  tree  which  correspond  to  the  Ada  package  or 
procedure  body.  while  creating  the  DIANA  tree  for  the  package 
specification  according  to  the  mappings  discussed  in  the 
Functional  Description.  This  includes  the  nodes  and  associated 
attributes  for  the  package's  context  specification  (WITH  and  USE 
clauses).  as  well  as  for  the  declarations  which  form  the  package 
specification  itself.  SPEC  also  adds  nodes  to  the 
J73_pr edef i ned_package  DIANA  tree  as  required. 


4.4.6  BODY 

The  second  pass  over  the  J73  parse  tree  is  made  by  BODY.  For 
compools.  which  are  translated  to  package  specifications  with  no 
package  body.  the  entire  DIANA  tree  is  created  by  SPEC;  BODY 
produces  no  output.  Conversely.  a  procedure  containing  no  DEF 
declarations  or  STATIC  declarations  is  processed  in  entirety  by 
BODY,  since  it  is  translated  to  a  procedure  body  (with  no  package 
specification).  In  the  general  case  (translation  of  procedures 
which  may  include  DEF  or  STATIC  data),  the  two— pass  process 
performed  bv  SPEC  and  BODY  permits  translation  of  the  J73  parse 
tree  to  DIANA  in  an  efficient  manner;  a  one-pass  technique  would 
involve  reordering  of  the  module's  declarations  and  statements  to 
separate  the  package  specification  part  from  the  package  bodv 
part,  requiring  more  complex  tree-processi ns  algorithms. 
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.4.7  GEN 

da  source  code  is  generated  from  the  DIANA  tree  by  the  GEN 
outine.  GEN  is  a  tree-wal k i ns  algorithm  which  creates  source 
ext  based  on  the  guidelines  discussed  in  references  Cd3  and  Cm3, 
n  particular.  each  node  of  the  DIANA  tree  created  bY  SPEC  and 
ODY  will  include  the  lx_comments  attribute  as  suggested  in 
ppendix  III  of  Cm3.  The  value  of  this  attribute  may  be  filled  in 
ith  a  reference  to  a  Translator-generated  comment  in  the  case  of 
node  that  represents  a  Translator-generated  statement! 
therwise,  the  attribute  will  contain  a  reference  to  an  original 
73  source  comment  (possibly  null).  GEN  -ill  use  the 
s_err or -number  and  as_error_l ink  attributes  (defined  in  4.3. 3. 3) 
o  generate  diagnostic  messages  and  J73  source  code  in  positions 
f  the  Ada  source  corresponding  to  translation  errors . 

he  output  of  GEN  is  a  text  file  which  is  used  by  LIST  to  produce 
n  appropriately  formatted  output  listing.  If  the  user  has 
eauested  a  listing  of  .J73_predef ined_packase»  GEN  will  also 
reate  a  text  file  based  on  that  package's  DIANA  tree. 


.4.8  LIST 

he  listings  output  by  the  Translator  are  produced  by  LIST.  Using 
he  diagnostic  files  created  by  ANALYZE.  the  dictionary 
epresented  by  ModTab.  and  the  Ada  source  files  created  by  GEN, 
1ST  outputs  prettypr inted  reports  requested  by  the  user  for  each 
ranslator  run. 
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APPENDIX 

Content*  of  the  Translation  Parameter  File 


The  followins  table  sroup*  the  translation  parameters  bv  class 
(comment  translation*  executable  construct  translation.  J73 
implementation  parameters.  control  of  output  listinss.  name 
translation,  and  names  of  prasmas)  and  sives  a  brief  description  of 
the  purpose  of  each  parameter.  (Notes  T.G.  means  "Translator 
senerated". > 


PARAMETER  PARAMETER 

CLASS  NUMBER  PURPOSE 


COMMENTS  Cl  Suppress  orisinal  comments 

C2  Suppress  T.O.  comments 

C3  Start  new  line  for  an  embedded  comment 

C4  Format  of  comment  for  T.G.  type 

declaration 

EXECUTABLE  El  Suppress  calls  to  roundins  routines 

E2  Suppress  calls  to  truncation  routines 

E3  Nam*  of  user  supplied  roundins  function 

E4  Nam*  of  user  supplied  truncation  function 

E5  Name  of  user  supplied  UNCHECKED-CONVERSION 

function 

E6  Convert  IF. ..EXIT  to  EXIT  WHEN... 

E7  Suppress  copvins  of  BY  VAL  parameters 

E8  Suppress  copvins  of  BY  RES  parameters 

IMPLEMENTATION 

PARAMETERS  II  Values  of  J73  implementation  parameters 


134 

LISTINGS  LI  Translation  of  tab  stops 

L2  Translation  of  form  feeds 

L3  Suppress  upper  case 

L4  Suppress  lower  case 

L5  Include  J73  source  in  diagnostic* 

L6  Suppress  informational  diavnostics 

L7  First  column  for  unlabeled  statements 

L8  Last  column  for  code 

L9  Last  column  for  comments 
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PARAMETER 

CLASS 


NAMES 


PRAGMAS 


PARAMETER 

NUMBER  PURPOSE 


N1  Translation  of  ' 

N2  Translation  of  embedded  * 

N3  Translation  of  laadins  * 

N4  Translation  of  namas  which  are  Ada 

rasarvad  words 

N5  Spall  ins  of  T.G.  typo  namas 

N6  Spall  ins  of  T.G.  function  result  namas 

N7  Translation  of  status  constant  namas 

N8  Maximum  numbar  of  charactars  racosnizad 

N9  Spall  ins  of  T.G.  packasa  names 


PI 

Name 

of 

PRAGMA 

P2 

Name 

of 

PRAGMA 

P3 

Name 

of 

PRAGMA 

P4 

Name 

of 

PRAGMA 

P5 

Name 

of 

PRAGMA 

P6 

Name 

of 

PRAGMA 

P7 

Name 

of 

PRAGMA 

PS 

Name 

of 

PRAGMA 

P9 

Name 

of 

PRAGMA 

PIO 

Name 

of 

PRAGMA 

Pll 

Name 

of 

1 

f 

for  contisuous  allocation 

for  ovarlayad  allocation 

for  'TRACE 

for  'INTERFERENCE 

for  'REDUCIBLE 

for  'BASE 

for  'ISBASE 

for  'DROP 

for  !LEFTRIGHT 

for  'REARRANGE 

for  .'ORDER 
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PREFACE 


This  report  was  prepared  as  part  of  the  JOVIAL  <J73)  to  Ada 
Translator  Investigation  C&3,  a  research  study  performed  by 
Proprietary  Software  Systems  for  the  Rome  Air  Development  Center 
under  contract  number  F30602— 81-C-0217.  Two  other  reports  were 
prepared  during  the  investigation*  a  Functonal  Description  [43, 
which  defines  the  requirements  to  be  met  bv  a  JOVIAL  (J73)  to  Ada 
Translator,  and  a  System/SubSYStem  Specification  C53,  which 
presents  a  top-level  design  for  a  Translator.  The  present  report 
is  intended  to  be  read  in  the  context  of  those  two  documents. 
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I.  INTRODUCTION 

A  superficial  inspection  sussests  that  the  lansuases  JOVIAL  (J73) 
and  Ada,  as  defined  bv  MIL-STD  1589B  C23  and  MIL-STD  1815  C33,  are 
«iuite  similar.  Both  lansuases  feature  separate  compilation,  strone 
tYPins,  block  structure,  and  compulsorv  data  declarations.  The  IF 
statement,  CASE  statement,  and  loop  constructs  of  the  two 
lansuases  are  almost  identical.  Each  lansuase  provides  operations 
on  fixed  point  and  floating  point  data,  in  addition  to  inteser  and 
character  operations.  Ada  is  a  much  more  powerful  lansuase  than 
J73,  since  it  includes  many  features  for  prosran  control, 
modularization,  and  data  description  that  are  not  found  in  J73. 
One  misht  conclude  that  J73  is,  in  an  informal  sense,  a  functional 
"subset"  of  Ada,  and  that  translatins  a  J73  presram  to  Ada  should 
be  a  reasonably  easy  task. 

Unf ortunately,  a  closer  analysis  of  the  lansuases  reveals  a  number 
of  fundamental  differences  which  render  the  translation  task 
exceedinslv  complex.  The  semantics  of  data  and  type  declarations 
is  a  case  in  point.  In  J73,  the  storase  for  a  variable  will  be 
allocated  statically  <i.e.,  permanently)  whenever  the  declaration 
of  the  variable  so  specifies*  in  Ada,  storage  is  allocated  by 
context  (i.e.t  for  the  life  of  the  module  in  which  the  variable's 
declaration  appears).  A  J73  type  is  defined  by  a  set  of 
attributes,  so  that  two  distinctly  declared  types  are  considered 
to  match  if  thsir  atttributes  match!  two  distinctly  declared  Ada 
types  are  always  considered  to  be  non-mat chine,  even  if  their 
attributes  are  identical.  The  attributes  of  a  type,  in  J73,  are 
defined  in  terms  of  tarset  machine  representation  (e.s.,  number  of 
bits,  physical  record  structure),  while  Ada  requires  only 
alsorithmic  attributes,  such  as  ranee,  error  bounds,  or  loeical 
record  structure. 

The  two  laneuaees  contain  several  major  differences  in  the 
semantics  of  executable  (run-time)  constructs.  J73  permits 
conversions  between  any  two  types,  while  Ada  prohibits  conversions 
between  any  two  types  which  are  not  closely  related.  Linkec 
structures  may  be  created  in  a  J73  rrosram  us ins  untyped  pointers 
to  reference  named  (declared)  objects!  Ada  allows  only  typed 
pointers,  which  may  reference  only  anonymous  objects.  The 
semantics  of  parameter  passins  are  defined  in  terms  of  bindins 
mechanisms  (value,  reference,  or  result)  in  J73!  Ada  defines  only 
the  effect  of  a  parameter  bindins  (input  or  output),  while 
carefully  avoidins  any  specification  of  bindins  mechanisms.  A  J73 
procedure  may  be  prematurely  terminated  usins  one  of  two 
constructs  ("GOTO  <statement_name.parameter>"  or  the  ABORT 
statement)  which  are  nothins  but  slobal  GOTO' s l  Ada  permits  only  a 
wel 1 -structured  mechanism  (the  raisins  of  exceptions)  to  exit  from 
a  procedure  prematurely. 
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The  incompatibilities  between  J73  end  Ade  »o  beyond  the  semantic 
differences  between  their  individual  constructs.  The  laneuaees 
have  dissimilar  Requirements  pertainin*  to  the  order  of 
compilation  of  modules.  An  Ada  compiler  must  have  access  to  slobal 
knowledge  of  external  names.  whereas  J73  externals  are  not 
resolved  until  link  time.  Both  lanvuaees  have  a  macro-definition/ 
expansion  facility*  but  J73  allows  full*  text-oriented  macro 
substitutions*  while  Ada  permits  only  procedure  definitions 
(penerics)  in  its  macros. 

The  major  differences  between  J73  and  Ada  are  summarized  in  the 
table  below.  These  differences*  plus  many  smaller  dissimilarities* 
cause  the  translation  of  a  J73  provram  to  Ada  to  be  exceedingly 
difficult*  whether  the  translation  is  done  manually  or  with  the 
aid  of  an  automated  system  <a  Translator).  The  portion  of  the 
translation  task  which  can  be  automated  is  discussed  in  detail  in 
the  Translator  Functional  Description.  A  discussion  of  the  portion 
which  requires  manual  translation  is  eiven  in  the  next  two 
sections*  followed  by  a  section  containing  some  vuidelines  for 
achievine  "cleaner"  translations. 
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Summary  of  J73/Ada  Incomeatibi  1  ities 


»  FEATURE 

I  Static  tnd  external 
I  allocation 

I  Typo  matchln* 

i  Attributes  of  types 

I  Ordor  in  which 
I  modulo*  mutt  bo 
I  compiled 

5  Tvm  convention* 

t  R*1 ot ion thin 
l  between  pointer* 

1  and  pointed-to 
1  data  object* 

1  Macro-*ub*titution* 

:  Parameter  pat* in* 

>  Abnormal 
(  termination  of 
I  procedure* 

S  Resolution  of 
i  external*  and 
I  parameter  matchin* 


I  J73 


Explicit 


Equivalent  type* 
always  match 


Tareet  machine 
oriented 

Imposed  only  on 
compool  dependencies 


Permitted  between 
any  two  type* 


Untyped  pointer*, 
named  data 


Text-oriented 

Defined  by  mechanism 

Unstructured  GOTO 
and  ABORT 


Link-time 


I  ADA 


I  By  context 

l 

I  Distinct  type*  do 
i  not  match,  even 
!  if  equivalent 

1  Algorithm  oriented 

I  Imposed  on  all 
1  modules 

I  Permitted  between 
1  two  closely  related 
»  type* 

1  Typed  pointer*. 

I  anonymous  data 
I  objects 

I  Procedure-oriented 

l  Defined  by  effect 

I  Hi*hly  structured 
1  RAISE  and  EXCEPTION 

I  Compile- time 
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II.  CLASSIFICATION  OF  PROBLEMATICAL  CONSTRUCTS 

Despite  all  the  fundamental  difference*  between  J73  and  Ada*  there 
is  probably  no  such  thine  as  an  untranslatable  cenetruct.  Given 
enoueh  analysis*  any  J73  proeram  can  be  converted  te  Ada*  FORTRAN* 
assembly  laneuaee*  or  virtually  any  laneuaee  which  is  intended  for 
use  on  a  conventional  <von  Neumann)  computer.  Unfortunately*  the 
analysis  and  synthesis  (i.e.*  reprosrammine)  required  to  translate 
certain  J73  constructs  to  Ada  autoisatical  1y  would  be  unreasonably 
expensive*  eiven  the  state  of  the  art  of  automatic  proerammine  and 
laneuaee  conversion.  A  cost  effective  strateev  is  to  automate  the 
bulk  of  the  translation  task  and  to  detect  and  identify 
(automatical ly>  portions  of  proerams  which  require  manual 
translation.  With  this  approach*  a  Translator  system  with  rouehly 
the  same  complexity  as  a  J73  compiler  would  perform  most  of  the 
translation  without  human  assistance*  while  flaeeine  the 
constructs  that  it  cannot  handle  properly.  These  problematical 
constructs  would  then  be  analyzed  and  translated  manually*  usino 
techniques  outlined  in  Section  III.  Before  discussin*  the 
translation  of  specific  problematical  constructs*  it  is  useful  to 
define  classes  of  constructs  accordino  to  ease  of  translatabi 1 ity. 

Most  J73  constructs  can  be  translated  to  Ada  usino  techniques 
which  may  be  automated  by  the  approach  discussed  in  the  Translator 
System/SubsYstem  Specification.  Such  "class-one"  constructs  are 
translated  usino  the  mappinos  described  in  the  Translator 
Functional  Description.  The  resultino  Ada  prooram  will  be  better 
(more  efficient  and/or  more  readable)  if  the  use  of  certain 
class-one  constructs  is  avoided  or  restricted  (see  Section  IV). 

Constructs  whose  translation  to  Ada  cannot  be  automated 
cost-effectively  ("problematical"  constructs)  fall  into  two 
classes.  An  instance  of  a  problematical  construct  which  may  be 
replaced  by  a  non-problematical  J73  construct  is  described  as 
"class-two".  Such  a  construct  may  be  manually  converted  to  a 
class-one  construct  to  facilitate  automatic  translation. 
Problematical  constructs  which  are  semantically  orthoeonal  to  the 
rest  of  the  J73  laneuaee  present  the  most  difficult  translation 
problems.  These  are  called  "class-three”  constructs.  Since  a 
class-three  construct  cannot  be  converted  to  a  class-one 
construct*  the  translation  requires  one  of  the  followine  actions* 

At.  Chanee  the  J73  proeram  aleorithmical lv  to  avoid 
usine  the  construct! 

A2.  Translate  the  rest  of  the  proeram  to  Ada  and  chanee 
the  Ada  proeram  aleorithmical 1y  to  avoid  usine  the 
construct! 
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A3.  Translate  th«  rest  of  the  pro*r*m  to  Ada  and  us*  * 
feature  (possibly  a  non-standard  one)  of  the  Ada 
environment  to  accomplish  the  function  of  the 
class-three  construct! 

A4.  Substitute  direct  code  (assembly  laneuae*  or 
machine  laneuave)  for  the  construct. 

The  actions  listed  above  may*  of  course*  be  taken  to  translate 
class-two  constructs  as  well  as  class-three  constructs. 

The  mappines  of  the  class-one  constructs  onto  Ada*  as  discussed  in 
the  Functional  Description*  are  intended  to  be  automated  (see  the 
Translator  System/SubsYstem  Specification)*  but  may  be  performed 
manually*  the  validity  of  the  mappines  is  independent  of  the  means 
of  implementation.  The  problematical  constructs*  class-two  and 
class-three*  must  be  hand-translated.  There  are  three  kinds  of 
problematical  constructs:  data-oriented  constructs  (table*  block* 
and  overlay  declarations)*  executable  constructs  (slobal  GOTO's* 
ABORT •'s,  and  expression  side  effects)*  and  compile-time  functions. 
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III.  TRANSLATION  OF  PROBLEMATICAL  CONSTRUCTS 


A.  Data-Oriented  Construct* 

A  J73  data  (or  data  type)  declaration  mav  specify  several  kinds  of 
data  overlap*.  For  example,  a  specified  table  mav  contain  items 
whose  bit  positions  (within  the  table  entry)  overlap  either 
partially  or  completely!  a  block  may  be  made  to  overlap  another 
block  usin*  an  overlay  declaration  and  an  order  directive!  overlay 
declarations  mav  be  used  to  position  several  data  objects  in 
overlappin*  positions  in  memory.  In  attempting  to  translate  these 
kinds  of  constructs  to  Ada.  one  must  consider  the  purpose  of  the 
construct.  A  particular  instance  of  a  problematical  data 
declaration  may  have  one  of  several  purposes! 

PI.  A  "true  overlay".  in  which  the  same  bits  of 

physical  memory  are  used  by  more  than  one  named 
data  object. 

P2.  The  allocation  of  storage  for  data  objects  in  a 

specified  order. 

P3.  The  allocation  of  contiguous  storave  of  data 

objects. 

P4.  The  allocation  of  storage  for  data  objects  at  a 

specified  memory  address. 

P5.  A  "virtual  overlay".  in  which  two  or  more  named 
data  objects  are  declared  to  occupy  overlappin*  bit 
positions  in  a  table  or  a  block,  but  the  data 
structure  is  accessed  as  a  variant  record  (i.e.. 
only  one  of  the  overlappin*  objects  Physically 
exists  in  each  record!  the  objects  do  not  really 
overlap) . 

A  person  wishin*  to  translate  a  problematical  data  declaration  to 
Ada  must  analyze  the  construct  in  the  context  of  its  provram  and 
determine  into  which  of  these  catevories  it  falls. 

A  "true  overlay"  may  be  treated  as  a  class-two  construct.  This  is 
accomplished  by  usin*  duplicate  storave  in  lieu  of  overlayed 
storave;  instead  of  declarin*  one  object  to  overlay  the  other,  one 
may  declare  the  objects  as  separately  stored  data.  In  the 
remainder  of  the  provram.  each  statement  that  changes  one  of  the 
objects  must  be  followed  by  a  new  statement  that  chanves  the  other 
object  in  the  same  way.  For  example,  a  provram  of  the  form 
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ITEM  ill... 

ITEM 

OVERLAY  11111121 


iil  «■  ...  "assignment  to  iil  also  assigns  ii2" 


is  changed  to 


ITEM  iil... 
ITEM  ii2. . . 


111  ■  ...  "assigns  only  iil" 

112  ■  iil?  "assigns  ii2" 


This  technique  has  two  major  disadvantages.  First*  it  is 
applicable  only  to  "cleanly"  overlayed  objects  -  objects  which  are 
partially  overlapped  (such  as  table  items)  could  not  be  recoded  in 
this  manner.  Second*  the  resulting  program  is  highly  inefficient; 
twice  as  much  storage  is  needed  for  the  separately  allocated 
objects  and  twice  as  many  assignment  statement  statements  are 
executed  during  the  program.  Because  of  these  disadvantages*  "true 
overlay"  constructs  should*  in  most  applications*  be  treated  as 
class-three  constructs.  An  implementation  of  Ada  may  (optionally) 
provide  an  overlay  construct*  allowing  action  A3  to  be  used.  If  an 
overlay  feat»'-g  is  not  available*  algorithmic  changes  (actions  A1 
or  A2)  are  required. 

A  P5  construct  ("virtual  overlay")  can  be  effectively  translated 
using  action  A3.  The  technique  is  illustrated  by  the  following 
example? 

TABLE  building  (100)...  "Table  of  data  about  two  kinds  of 

buildings?  home  and  business... 
one  entry  per  building" 

BEGIN 

"The  following  items  are  used  for  all  buildings?" 

ITEM  zipcode  U  17  POS  (0.0) ? 

ITEM  kind  STATUS  (v(home),  v(business))  POS  (17,0)? 

"The  following  item  is  used  for  business  buildings  only?" 

ITEM  name  C  10  POSCO,  D?  "name  of  business" 

"The  following  items  are  used  for  homes  only?” 

ITEM  bedrooms  U  3  P0S(0, l>?  "number  of  bedrooms" 

ITEM  baths  U  2  P0S(3,l)f  "number  of  baths" 


END 


0-7 


TO  ADA  TRANSLATOR  INVESTIGATION 
INES  FOR  TRANSLATION 


is  data,  structure,  the  items  "bedrooms"  and  "baths"  do  not 
Iy  overlap  “name".  Instead,  the  item  "kind"  is  used  as  a 
ninant  to  select  one  of  two  alternate  structures  for  each 
entry.  This  is  semantically  equivalent  to  a  variant  record 
.  If  the  table  declaration  is  translated  to 

bui 1 dine_kind  IS  ( home, business ) : 
bui 1 dins_type  (kind:  bui 1 di ns_ki nd )  IS 
ECORD 

zipcodei  U17_type! 

CASE  kind  IS 

WHEN  business  *>  name:  C10_type? 

WHEN  home  «>  bedrooms:  U3_tYPel 

baths:  U2_typel 

END  CASE: 

«D  RECORD! 

din**  ARRAY  (O. ..100)  OF  bui 1 dino_tYPei 

assignments  to  all  the  items  within  an  entry  of  "building" 
made  using  aggregate  rotation.  Thus,  the  statements 

t>de<22)  -  134111 
(22)  «  2: 
t>oms(22)  ■  4: 

anslated  to 

ding(22)  :»  ( home, 1341 1 , 4, 2) :  —  positional  record  aggregate 
jivalentl y, 

ding(22)  *■  (kind  *>  home,  zipcode  *>  13411,  baths  *>  2, 

bedrooms  *>  4):  —  named  component  aggregate 

scord  aggregate  used  in  the  assignment  includes  a  value  for 
(the  discriminant  of  the  record),  whether  one  uses  the 
>nal  notation  or  the  named  component  notation. 

Lgnment  to  an  individual  item 

t(22)  ■  2: 

islated  to 

ding  (home)(22)  :■  21 

Ich  the  discriminant  is  given  on  the  left  hand  side  and  a 
I  (rather  than  an  aggregate)  is  given  on  the  right  hand 
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The  um  of  •  vtritnt  rocord  for  this  kind  of  translation  results 
in  Ado  codo  which  is  both  officiont  ond  seMnticallv  equivalent  to 
tho  orieinal  aleorithm  of  tho  J73  codo. 

When  on  ovorlov  declaration  is  usod  for  purpose  P4  rothor  thon  for 
o  “true  ovorloy".  it  my  bo  translated  to  on  Ado  oddross 
seecif icotion.  For  oxosrloi 

OVERLAY  POS  < 4FFF 1 *  block!  I 
is  equivalent  to 

FOR  blockl  USE  AT  1444FFF*  I 

Ovorlov  declarations*  block  declarations*  ond  ordor  diroctivos 
which  oro  usod  for  purposes  P2  ond  P3  oro  not  covorod  bY  tho 
seMntics  of  Ado  os  oivon  bY  the  lanouooo  stondord.  Tronslotion  of 
such  constructs  my  bo  ochieved  bv  oction  A3  if  tho  Ado 
comet lor/onviron«ont  to  bo  used  offers  optionol  footuros  for 
ovorlovino  or  ordorino  of  storooo  allocation.  Otherwise*  stJor 
aleorithmic  chonoos  will  bo  required. 


S.  Executable  Constructs 

When  on  ABORT  stotowont  is  executed*  tho  J73  procedure  currontlv 
oxocutino  will  terminate  (return  without  sottino  onv  value  or 
result  parameters),  ond  execution  proceeds  at  tho  stotOMnt  whoso 
label  appeared  in  the  abort-phrase  of  the  most  recent  procedure 
coll  statement  which  included  on  abort-phrase.  If  there  wore 
intermediate  procedure  colls  without  abort-phrases*  then  those 
intorsiedioto  procedures  oro  also  terminated!  if  no  procedure  colls 
included  on  abort-phrase*  a  STOP  is  executed.  Tho  difference 
between  the  ABORT  statement  and  the  Ada  RAISE  statement  is  that 
the  ABORT  my  result  in  a  transfer  to  aax  uet  of  the  procedure 
which  handles  the  ABORT.  The  exception  handler  which  is  invoked  bv 
a  RAISE  statesent  must  appear  at  the  and  of  the  procedure  in  which 
it  appears!  the  handler  acts  as  a  substitute  for  the  reMinder  of 
the  cal  line  procedure.  In  effect*  a  J73  ABORT  is  handled  bv 
executine  an  unrestricted  GOTO  within  the  cal  line  procedure*  while 
Ada  permits  a  procedure  termination  to  be  handled  onlY  bY  a 
structured  exit  from  the  cal  line  procedure. 

The  J73  statement  name  parameter  is  used  to  terminate  a  procedure 
with  an  unrestricted  GOTO  in  the  same  manner  as  the  ABORT*  but  at 
one  level  of  procedure  calls  rather  than  anY  number  of  levels.  The 
statement*  "GOTO  <stetement_name_perameter>"  is*  therefore*  a 
special  case  of  the  ABORT  statement!  the  two  constructs  share  the 
same  class-three  incompatibility  with  Ada. 
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Two  techniques  are  available  tor  translating  a  program  which 
contains  either  of  these  constructs.  The  first  involves  an  A4 
action*  replace  the  ABORTS  and  global  GOTOs  with  calls  to 
machine-level  runtime  routines*  effecting  the  handling  of 
procedure  termination  at  the  target-machine  level  rather  than  the 
high-order  language  level.  The  second  technique  is  an  algorithmic 
change  <A2>  which  restructures  the  calling  procedure*  placing  the 
logic  which  handles  the  ABORT  or  GOTO  at  the  end  of  the  procedure. 
Once  this  restructuring  has  been  accomplished*  the  abort-phrase  or 
statement  name  parameter  is  replaced  bv  an  exception  declaration* 
the  end-of-procedure  logic  is  labeled  as  an  exception  handler*  and 
the  ABORT  or  GOTO  is  replaced  bv  a  RAISE  statement.  This  technique 
of  processing  procedure  terminations  may  be  used  for  any  number  of 
statement  name  parameters  or  abort-phrase  values*  since  multiple 
exceptions  may  be  defined  within  the  same  procedure.  The 
programming  of  exceptions  is  discussed  in  detail  in  the  Ada 
language  standard  <in  particular*  see  Section  11.4.1)*  a  lucid 
discussion  of  the  definition  and  propagation  of  exceptions  may  be 
found  in  Chapter  10  of  Barnes  C1D. 

The  J73  language  guarantees  that  the  right-hand  side  of  an 
assignment  statement  will  be  evaluated  before  the  left  hand  side* 
and  that  function  arguments  and  table  indices  will  be  evaluated* 
left  to  right*  before  any  expressions  or  assignments  are 
performed.  This  means  that  the  statement 

xx  =  fund ("expression  1")  +  func2< “expression  2">« 
may  have  a  different  effect  than  the  statement 

xx  *  func2< "expression  2")  ♦  fund < "expression  1")* 

if  the  evaluation  of  expression  1  causes  a  change  (side  effect)  in 
the  value  of  expression  2.  A  J73  program  mav  actually  rely  on  this 
effect*  an  Ada  program  may  not.  Beside  avoiding  such  dubious 
programming  practices*  a  programmer  may  remove  order-of-eval uation 
dependencies  from  expressions  and  assignments  by  breaking  up  t..e 
expressions  into  separate  statements.  For  example*  if  the 
proceeding  assignment  statement  needs  to  have  expression  1 
evaluated  first*  then 

xx  ■  fund  ( "expression  1")* 

xx  *  xx  func2(  "expression  2")* 

may  be  substituted  for  the  original  statement.  This  technique  may 
be  applied  as  either  a  J73  modification  (treating  it  as  a 
class-two  problem)  or  as  a  change  to  the  Ada  translation  of  the 
program.  In  either  case*  the  side  effect  dependencies  must  be 
detected  and  eliminated  manually. 
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C.  Comp il •-Tim*  Function* 

Bacausa  Ad*  lacks  a  taxt-oriantad  macro-carabil itv.  tha  DEFINE 
call*  in  a  J73  rrosram  must  ba  expanded  at  translation  tima. 
Therefore.  tha  DEFINE  declaration  and  tha  {LISTINV.  ‘LISTEXP,  and 
!LISTBOTH  diractivas  ara  simply  discardad  rathar  than  translatad. 
Othar  J73  diractivas  which  hava  no  Ada  equivalents  may  ba 
translatad  only  if  tha  Ada  anvironmant  to  ba  usad  contains 
optional  faaturas  which  corraspond  to  tha  J73  diractivas.  In 
particular,  tha  !TRACE  diractiva  will  ba  implamantad.  in  soma 
form.  in  avarv  Ada  anvironmant.  Othar  diractivas  ( {REDUCIBLE. 
•BASE.  ! ISBASE.  'DROP.  {INTERFERENCE.  'LEFTRIGHT.  and  {REARRANGE) 
hava  no  runtima  samantic  affact;  thav  simply  aid  tha  J73  compilar 
in  rerformins  cartain  coda  optimizations.  Sinca  thasa 
optimizations  do  not  chanaa  tha  samantic*  of  tha  proaram.  and 
sinca  Ada  compilars  ara  axpactad  to  parform  subtla  coda 
optimizations  without  tha  assistanca  of  such  diractivas.  it  is 
likalv  that  tha  dalation  of  thasa  diractivas  from  a  translatad 
prosram  will  hava  no  datrimantal  affact. 
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IV.  PROGRAMMING  GUIDELINES 

In  the  preceedins  sections*  the  translation  of  problematical 
constructs  in  existin*  J73  programs  was  discussed.  If  a  J73 
pro* ram  is  to  be  written  with  translation  to  Ada  planned  for  the 
future*  the  prosram  should  avoid  the  use  of  all  the  problematical 
constructs.  A  J73  pro*ram  containing  only  class-one  constructs 
will  be  (relatively!)  simple  to  translate?  in  fact*  it  will  be 
automatically  translatable.  However*  the  J73  programmer  can  so 
beyond  merely  writin*  a  non-problematical  program.  Th •*  Ada  program 
that  is  produced  by  the  translation  process*  whether  manually  or 
automatically*  will  be  of  significantly  hisher  eualitv  if  the 
followin*  suidelines  are  observed  by  the  J73  pro*rammer* 

1.  Do  not  use  untyped  pointers.  Every  pointer 

declaration  should  include  a  specified  type*  so 
that  translation  to  access  types  is  simplified. 

2.  Avoid  conversions  between  unrelated  types.  Ada  does 
not  permit  such  conversions*  except  by  use  of  the 
seneric  function  UNCHECKED-CONVERSION*  which  is 
somewhat  cumbersome  to  instantiate  and  call  for 
every  type  of  conversion. 

3.  Do  not  use  names  containin*  more  than  one 

consecutive  *  or  ".  This  practice  will  avoid  the 
veneration  of  awkward  names  usin*  underscores  in 
the  Ada  prosram.  In  fact*  the  names  in  the 

translated  prosram  will  be  much  cleaner  if  the  J73 
names  use  either  *  or  '»  but  not  both. 

4.  Limit  the  lensth  of  names  to  much  less  than  the  32 

characters  permitted  bv  J73.  Many  translation 
functions  require  the  veneration  of  type  names 

based  on  addin*  an  extension  to  an  object  name  (or 
veneration  of  packave  names  by  addin*  an  extension 
to  a  procedure  name)*  which  may  result  in 

excessively  Ion*  identifiers. 

3.  Do  not  use  the  FALLTHRU  construct.  Its  translation 
is  both  awkward  and  inefficient. 

6.  Avoid  loop  statements  with  by-clauses  or 

then-clauses  which  result  in  a  loop  increment  of 
other  than  one.  Virtually  any  function  that 
requires  a  loop  can  be  coded  usin*  either  a  FOR 
loop  with  an  increment  of  one  or  a  WHILE 

<condition>  loop*  both  of  which  have  simple  and 
efficient  Ada  translations?  loops  with  increments 
not  eeual  to  one  can  be  translated*  but  not  as 
cleanly. 
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7.  Avoid  elaborate  DEFINE  usaee.  DEFINES  will  be  lost 
in  the  translation  rroctts. 

8.  Declare  elobal  data  in  compools.  Individual  data 
declared  as  externals  in  procedures  results  in  a 
much  more  complex  translation.  Similarly*  static 
data  should  be  declared  in  compools  or  in  the  main 
proeram*  not  in  procedures. 

9.  Keep  table  structures  as  simple  as  possible. 
Proerams  which  use  parallel*  packed*  or  variable 
entry  tables  will  be  much  harder  to  translate  to 
Ada  than  programs  which  use  straight* orward  tables. 

10.  Include  detailed  comments  about  non-trivial  data 
structures.  Tables*  blocks*  and  the  code  which 
accesses  them  can  be  translated  much  more  easily 
<and  tested  much  more  reliably)  if  the  personnel 
doine  the  translatine  and  testine  understand  the 
purpose  of  the  data  structures. 

11.  Include  detailed  comments  about  pointer  usaee.  Ada 
features  very  powerful  instructions  for  dynamic 
allocation  and  access  of  linked  data  structures. 
These  features  may  be  exploited  by  manually 
recodin*  portions  of  a  program  (after  translation) 
in  Ada)  a  direct  translation  will  not  make 
efficient  use  of  these  features.  This  process  will 
be  facilitated  by  the  liberal  use  of  comments. 

12.  Avoid  GOTOs  and  deeply  nested  procedures.  This  will 
improve  the  readability  and  maintainability  of  the 
prosram  in  both  J73  and  Ada  versions. 


G-13 


JOVIAL  TO  ADA  TRANSLATOR  INVESTIGATION 
GUIDELINES  FOR  TRANSLATION 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 

Many  ambaddad  softwara  SYStams  which  art  currantly  codad  (or  bain* 
codad)  in  J73  ara  to  ba  usad  and  maintainad  in  tha  mid  1980's  and 
bavond.  Such  .systams  should  ba  considarad  as  candidatas  for 
translation  to  Ada.  Tha  modif ication*  anhan*amant*  and  raaair  of 
ambaddad  sys tarns  will  ba  much  mora  aconomical  if  tha  (nradictad) 
banafits  of  tha  Ada  Prosram  ara  axnloitadl  tha  Ada  Standardization 
Program  suarantaas  that  thas.a  banafits  will  ba  availabla  only  for 
Ada-codad  sys tarns.  As  shown  by  tha  Functional  Dascription  and  tha 
Systam/SubsYstam  Sracif ication*  a  Translator  can  ba  immlamantad  to 
rarform  tha  vast  majority  of  tha  convarsion  to  Ada  of  a  larva* 
raaltima  provram.  Tha  translation  vrocass  must  not  ba  considarad 
to  ba  "cookbook"  in  natural  avan  a  wal 1 -dasivnad  Translator  svstam 
will  ba  unabla  to  rroduca  a  flyabla  Ada  vrovram.  Tha  translation 
of  rroblamatical  J73  constructs*  as  wall  as  tastin*  and 
inta*ration  of  tha  Ada  nrosram*  will  raauira  hi*hly  skillad 
rarsonnal*  whathar  or  not  a  Translator  is  usad.  Howavar*  tha  total 
labor  costs  of  nroducin*  a  flyabla  mrovram  will  ba  *raatW  raducad 
if  such  a  tool  is  availabla. 
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